|
|
Posted by bob.chatman@gmail.com on 09/30/07 08:12
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.
Navigation:
[Reply to this message]
|