Bruce,
i had initially thought that i could have the following tbl structure:
UniversityTBL (
name
ID auto_increment,
)
In a generic kinda "Best Practice", things I've picked up from various
places way I'd recommend the following things: -
1) The first field always be the Primary Key and always call it 'ID'.
2) The second field onwards should contain your Foreign Key fields
usually postfixed with FK, although ID is fine.
3) In an Object Orientated approach the attributes of the object come
next so Name, post code whatever...
4) Lastly put a Soft_deleted enum (Y/N), Date_modified
(CURRENT_TIMESTAMP default, and that auto update thingy) and
Date_created timestamp on the end for auditing purposes
5) Index anything with ID or FK in it.
6) Don't bother with the TBL in the table name.
7) Choose and stick to a capitalization, pluralization and underscores
for spaces policy, whatever floats your boat most is fine.
my question though, is, is this approach the best. i'm also considering the
Long and the short of it yes.
the single tbl would be:
tbl
name
parentID
ID
Don't for the love of all that's good! I've seen this carried to the
extremes and it makes your nose bleed after a while, there are perfectly
legitimate and good reasons for adopting this approach but it's probably
a bad idea when the rows are going to represent different types of object.
You won't be able to determine what type of object each record is,
you'll end up with a gigantic blob of a table and it'll have a million
different fields that don't apply to the 75% of the individual records.
Given the complexity of your problem and the fact that your all most
certainly using an OO language stick with representing each object with
it's own table.
this could work.
That's what they said about the chocolate teapot. Don't, trust me it's
not a good idea.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
