NYCPHP Meetup

[Roland Cozzolino]

That is a very valid point, ...however (there has to be some sort of 
argument) ... if you have a table with N-million rows, chances are your 
DB design isn't very good.  No hierarchical algorithm will perform well 
under conditions like that.  Nested sets will at least give you great 
retrieval times and tons of flexibility with the hierarchy nodes, 
whereas adjacency lists are very stringent and slow and will still end 
up giving you 3 bazillion rows.  Furthermore, if you are in fact dealing 
with that many rows, go buy Oracle or use PostGres (which can also 
partition across tablespaces and allow for OO design).  In my opinion, 
MySQL just falls short when you get into real complicated database 
design (I am ducking under my desk right now, fearing the MySQL fan-base 
may come over my house and shoot me).

Mitch Pirtle wrote:

>On 10/27/05, Hans Zaunere <lists at zaunere.com> wrote:
>  
>
>>Ahh, good old NSM...
>>
>>New York PHP developed an implementation of NSM, pNSM, as part of the clew
>>project.
>>    
>>
>
>Then let's start that discussion over here, about the performance
>benefits that turn into performance hits when your one table has 300
>million rows...
>
>Seriously, this concept makes lots of things seem easier, but next
>thing you know, you got a really looooooong table on your hands and
>only Oracle (IIRC) can partition across tablespaces at the table
>level.
>
>What to do when your nested table becomes more than you can manage? Is
>it time then to go back to a more normalized model, or is this an
>indication that - before you even implement - you have to take the
>eventual number of rows that your nested table might have to manage?
>
>-- Mitch, loving database discussions for a change ;-)
>_______________________________________________
>New York PHP Talk Mailing List
>AMP Technology
>Supporting Apache, MySQL and PHP
>http://lists.nyphp.org/mailman/listinfo/talk
>http://www.nyphp.org
>
>  
>