Re: Data Model

Frank,

I'm curious as to why you can appreciate that a single table was used. Not that I specifically agree or disagree, I'm open, I would just like to know your reasoning behind it.

My decision to go with a DB is stated above. To further elaborate, I'm big on flexibility, maintainability, and scalability. I've seen and inherited in the past some microsoft access applications that were designed with "Tunnel Vision". By tunnel vision I mean just solving a very specific problem without thinking about future changes or modifications, and when things got out of hand it got dumped on me. Meaning ridiculous hacks had to be made to add new functionality, but if the system data was normalized in the first place, it would have been a walk in the park. I'm NOT trying to attack you or your proposed solution, its just that I find writing directly to file not the direction I want to go in, for reasons stated in an earlier posting, mostly scalability in a disconnected web environment. But I can be convinced and am always open to other methods. I just need a little more reasoning.

In fact this thing I've built is a mini cms. The reason I want the 1 table normalized is so that I can enforce restrictions within the content, ie.me having a little more control. I also want the data (content) meaningful for future considerations. For example, I can see future enhancements to the website that would need meaningful data, and not just content to fill a <td></td>. Future redesigns may leave the existing content useless, but if it is forced and stored in the system as meaningful relational data, it makes it flexible and future proof to me. For example, what if judges decide they no longer want their zip code ( pick a field really, doesn't have to be logical ) showing in their page, but a NEW process else where requires a letter head to be printed. If I have a field in that one table/file for that "city state zipcode" content space, as it was previously designed, how would I know what "format" the user decided to use, so I can find the zipcode? What if they decided they no longer wanted the city to show, so they just delete it out of the field? How can I keep this consistency the higher ups desire in the look and feel? What if in the future they want a new search feature? One letter head says this, the other says that. I admit, that may be a poor example, and is not a current specification, but my point is I don't know what curve balls these people might throw out in the future. I can't afford to design with Tunnel Vision. Don't take that personal.

Can meaningful and relational data all be stored in one table? Yes, but what's the point of that. Performance is not an issue here. Data Integrity is higher on the latter. Not that performance itself is less of a priority, but with todays machines reading/writing to file is comparable to reading/writing from a db. Besides, reading/writing data is not a bottle neck for my environment, large _at_ss images are! How much difference in performance is the joining of 3 tables, as opposed to a single read to one table? It's very, very, very unnoticeable for this scenario. Not nowhere as beneficial as relational data.

All CMS systems that I know of that could handle this situation cost way t$$ much. But, I am open to suggestions and alternate methods for handling this scenario.

Theory has served me well, but common sense and simplicity are my best friends in practice. Remember, there was a time you couldn't even type, good thing you've taken a few theory classes since then.

Thanks for your post,

Matt Received on Sat Mar 04 2006 - 04:31:36 CET