Hi!
Im building a site for internal use for a company i work at.
And im having hard to decide what to do. The alternatives are
comma separated lists vs separate tables.
For example.. I will use a number of different type of objekt that all will hold 1 or more document links, phone numbers, emails etc
As far as i can i i have 2 possibilitys. One is to add textfields for each of these subojects in each objects tables. Then i add all info as commaseparrated lists in 2-3 layers wich i then save in the respecive objects fields.
(Look like something below for example )
,comment'emailadress,comment'emailadress,
Or i add 1 table for each subobject type wich manage the subobjects or link between different objects
for example:
table layout for email:
id | parent_type | parent_id | comment | email
Or for example contacts a mediator table:
id | parent_type | parent_id | contact_id
Hope you understand what i mean, would really appriechiate suggestions, comments regarding what can be considered as "best practise" in these cases. Putting it in separate tables should make searches easier, and coding easier in my book. But again im thinking if perhaps commalists is a faster and more recource conservative way of doing it + to me it feels like (perhaps i have no reason to think this?) making tables for items like feels like a timebomb if you exhaust your idfields identity count. Though this app will be used by perhaps 100ppl at most so perhaps not an extremely utilized webapp.
Anyway glad if you could give me some input!
I prefer seperate tables, as this gives clearer description of data structure/relationship, and it is much easier to manipulate the data in seperate tables.|||
Yeah well separate tables sure is the easiest way to get around it considering searches, changes when built etc.
Practically for me it will mean perhaps 3-5 querys in one page instead 1-2. So that is the main drawback i guess wich perhaps wont inflict to much.
Anyway my main concern was if there was anything that motivated commalists or its just a small gain for quite a bit more work in creating/changing.
|||"if you exhaust your idfields identity count"? If you were inserting a new record once every second non-stop, it'd take over 68 years to exceed the limits of an int. And when you get there, consider upgrading to SQL Server 2050 which solves that problem automatically for you. But if you think there is the possability that your app will need to run for 68+ years without a change, or if your think you'll need to insert more than 86,000 rows per day, then you might consider a bigint.
|||
Yeah did som calculations and came to the same conclusion ;)
Anyway think i will go for tables, for convineance sake.
Yeskin Gallen: