|
|
Posted by --CELKO-- on 11/11/06 23:16
>> I am using email addresses as relational keys. each and every table has an email associated with each row. <<
Good; make sure that you have ON DELETE/UPDATE CASCADE clauses on the
referencing tables. m
>> this is part of the profile owner's description. about_me is TEXT and describes the users background. interests, again TEXT, is more specific. <<
Have you ever filled out a survey card that came with a consumer
product? They often have a list of interests (travel, boating, movies,
etc.) -- that is how you encode specific data like interest and not in
free-form text.
>> I am not sure if that is correct about the BIT values. The value indicates an action taken, such as a rejected or accepted request, and I dont see how else to do this. <<
After 20+ years with SQL and RDBMS, I am sure. You are using
low-level, highly proprietary data types. Give me the action and the
date that the action was taken, not an assembly language style flag.
>> or, i dont see the point to improving on this method. what is being harmed by this? <<
Growth of the code, validation against the rest of the history and data
loss.
>> I like the idea of having an overall table for my profiles, as there are about 30 individual tables at this point that describe different features of the profile (EditProfile, AddList, PersonalPhotos, etc). I am not quite sure how to procede doing this. I'll do some reading on this, in the mean time; am i doing any harm by continuing to build my system the way i am? can the aggregate table be created at a later date without much reverse engineering? <<
I cannot say; I have no specs. But 30 tables seems like a lot for a
personal profile and perhaps a bit low for a full medical history.
Instead of pushing ahead with a weak design and then trying to fix it,
I would stop and spend the effort on getting it right at the start.
There is the "cowboy coder" impluse to code something in two minutes
with proprietary tricks and a short-term view of efficient architecture
rather than take two days (or even two months!) to research standards
and come up with a consistent, portable, verifiable design.
Navigation:
[Reply to this message]
|