Hello,
I have question about inheritance.
The website is going to handle millions of users.
This is about a social networking in the music industry.
We will have three different kinds of user:
1. Artists
2. Businesses
3. Fans
A user has a username , a password , an address , a phone number.
An artist plays one or several music instrument , and has one or several genders.
A business has has a or several categories , has method payments , hours of operation , a sic code and plenty of other stuffs.
A fan is basically a person who has some tastes.
My opinion is to create a users table , a personnal table (for person), a artists table and a businesses table and link them in a smart way.
Concerning my co worker he prefers to have a users table and put all fields in it and leave them blank if the user does not need this information.
Citation:
spwinston :
This way all that would be necessary to add a business profile onto a user would be to add in the field information rather than updating two tables, you only update one.
Citation:
spwinston :
It's a faster function as it requires less transaction costs on the SQL and less data by two ints at least.
[8:23:44 PM] spwinston a dit : why not leave it blank? that's a null set, makes for less diskspace used to save the information and faster lookups.
Citation:
Rémi: I agree but somehow it"s not really optimized , imagine that tomorrow we need 150 fields for a business u gonna add thesse 50 fields in the users table? it's gonna be ...
[8:24:34 PM] spwinston a dit : I'm confused as to how that's an issue???
[8:24:36 PM] Rémi a dit : This just a jointure but it saves a lot of room
[8:25:34 PM] Rémi a dit : like if we have 1 billion user , u gonna have million mutliplied by 150 fields left blank. u see? I am gonna show u some docs about inheritance if u don't mind , I just want to argue
[8:26:01 PM] spwinston a dit : I think that's not exactly true... in order to join it, you must have two like fields on which the dataset has to agree... that's two ints on both tables that must be saved to get the correlation correct... multiply the size of an int by 1 million+ records... then by 2... that's the cost of disk space... add in the cost of the transactions...
Leaving them blank isn't an issue as blank fields are null... this means they don't take up disk space.
[8:27:36 PM] spwinston a dit : 1 billion records on both ends would mean you're talking about roughly 100 megs of information required for a join statement... whereas 1 billion records full of null fields mean only 30-40 megs of information stored depending on the indexing of the table type.
However, take a look at the CLR book (ask a prof what the CLR book is if you don't already know), and look up how AB+ trees work... All databases at their core are ab+ trees. The idea is you index the ability to get to the information so the size of the index is the cost, however, null data means that the actual data isn't there or stored in the database.
thus if the children of a AB+ tree are null then the index or hash that's kept notes that... you're thus storing a single int for the index per row in your database which must be stored no matter what... if there's data in it, then it's a bitmask to check if there's data there... this makes it fast and stores less data.
What is the solution?
thanks!
I have attached a data drawing that I am thinking.
http://www.developpez.net/forums/attachment.php?attachmentid=17056&d=1185327679
Edited 1 time(s). Last edit at 07/24/2007 07:57PM by Remi DESREUMAUX.