Posted by Bruno Barros on 09/30/07 11:02

On 30 Sep, 09:12, "bob.chat...@gmail.com" <bob.chat...@gmail.com>
wrote:
> On Sep 29, 1:48 pm, Bruno Barros <rage...@gmail.com> wrote:
>
>
>
> > > That's one way to do it. But it's not necessarily a good database
> > > design. If there is information specific to that user, I include it in
> > > the same table. Among other things, it saves unnecessary joins.
>
> > No need to join, just fetch both tables and process the results. Then,
>
> > $who_is_logged_in == 1; // Just an example saying the user that is
> > logged has an ID of 1.
> > $user_who_is_logged_in_data ==
> > $data_from_second_table[$who_is_logged_in];
>
> > I prefer to do this way. And what I meant was not to do using two
> > tables, but that it would be more profitable on an abstraction basis,
> > as you would never have to deal with the first table, which was
> > absolutely important. Of course you don't need to use my method,
> > afterall, it's my framework ;).
>
> > > But this doesn't belong in a PHP newsgroup, anyway. It's more
> > > applicable to a database newsgroup.
>
> > Doubt it. All they could do was tell you the best way to link the
> > tables and do all that DB stuff. What we PHPers want is the best
> > minimal way to get a working user system.
>
> > ---
> > Bruno Rafael Moreira de Barros
>
> > Adobe Photoshop CS2 and CS3
> > -
> > XML / XSLT
> > -
> > MySQL / SQLite / TerraDB
> > -
> > PHP 3, 4, 5 and 6
>
> > :: Looking For A Permanent Job ::
> > ---
>
> Doesnt fetching both tables kill the logic that is provided in keeping
> your data separate? when i first started studying application design
> my teacher sat down and explained that if there is a way to simplify
> your application you should do it, and i see what you have said here
> to be kind of difficult to parse.
>
> Why would you not take advantage of something the database provides,
> even if you are able to handle processing in your application, since
> you would be using a smaller data set and most likely focusing on the
> data that is actually being used on that page? I would be really weary
> of an application that just grabbed everything from the database and
> processed it in its own code when it didnt need to. Ive seen it a
> couple times and as time goes on, as has been brought up above, your
> application will lose its responsiveness and eventually become
> useless.
>
> im glad that we have brought things back to the PHP end of things, but
> i dont want to come off half cocked. I am certain that application
> design is much more than the language you choose to build it in, and
> if you are going to say that grabbing all your information at once and
> processing it in your framework is your choice means of doing things,
> but i would really like to see the benchmarks that would support that
> means of development. I am fairly sure that your framework is playing
> with fire, and i fear for anyone who chooses to follow that pattern of
> development.
>
> SQL is an extensive language so you don't have to bother dealing with
> most processing issues, such as the one you have shown here.

Yes I know, but I just spoken about that for the way of separating
things (the user login and the user data). Of course it can be done, I
just explained the PHP way of doing it.

[Back to original message]