Eric, >... > This is crucial to me because what people have done up to this > point is create all these rediculous, non descriptive column names. > FirstName could quite possibly be in 10 tables. So what people have > done is just add characters to the beginning. Then someone go so fed up > with trying to think about it, they didn't care what the name was (I > have a table that has 6 date columns, 2 of which are Date1, and Date2). > I want things done right this time around, and Rbase is forcing me into > bad practices.
I think I understand what you're driving at... but if you're upset about ambiguous stuff like Date1 and Date2, why would you want 10 columns named "FirstName" if they aren't used in the same context? It could only be worse if they "were" in the same context. I don't know what the economics of the project are like, but if the time is available, sort through the schema and truly "do it right" this time (absolutely not meant to be offensive, just acknowledging the scale of what "do it right" means). I just got back into town, and read something like 30 responses to this, and no one called into question the _need_ for more than one column name of the same name. You know your design is really getting "right" when there are very few duplicate column names even if they _are_ in the same context. I know this can be taken to silly extremes, but !!10!! tables with a column name FirstName??? Sheeze. Assume that a few of those columns actually do refer to the same person and there is a typo. Either the user has to make multiple corrections or you have to maintain code that does. If your firstNames do talk about tree-bark and dog-bark, then you only need two, and frankly, I don't much care what you call them (as long as there are lots of comments <g>). Insisting that like column names have the same definition is just a characteristic of RBase. I don't view that standard as a bad practice (I personally like it because it helps me catch _unwanted_ duplicates); but it wouldn't hurt my feelings if that wasn't the case either. I will take issue with the idea that insisting that like names have like definitions is what defines an RDBMS. SQL handles the relationships. This rule just helps keep things tidy, imho. The real challenge for you Eric is cleaning up the mess <g>. Ben Petersen ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l
