Re: Data Model

David,

Thanks for your response and feedback. My goal was not put out my problem and have someone else find a solution, its already finished and going through change control. I just wanted to see what different things people would come up with. Let me address your questions. Please keep in mind I am responsible for all aspects, so I am not an expert in all areas. Feel free to shoot down my reasons for doing what I've done.

> First, go to www.databaseanswers.org and see if there's a model in there for court scheduling.

Thank you, I'll be sure to mine that area for future projects. There is already a program here that handles court scheduling. This is just to handle content for web pages.

> Second, the above "scenario" doesn't say what the data is for. The above
sets the scene, but dioesn't really state the scenario. I apologize for
nitpicking about language, but I think the distinction is worth it in this
case.

As stated in my post above, this data is for a website. The data needs to be updated by users the page needs to reflect that with no additional manual labor, such as a manual publishing request. Please navigate to this website to see how the data is displayed currently. Keep in mind users must be able to update their content without knowledge of html. A global cms system is not an option. http://www.justex.net/civil/11/

> Third, I have seen a package sold for this sort of thing, and it uses SQL
Server to make the data permanent. This package, when I looked at it, had
made the logical structure of the data so opaque that trying to use the data
for another purpose, via SQL server, was worse than hopeless. I didn't bid.

I haven't the time to go through that process, the deadline is next friday, the 10th and I started this past monday, the 27th. The civil courts move into their brand spanking new building and want it up by then.

>Fourth, why do you want to use a database? Are you trying to solve a
problem that files won't solve?

Most projects that house data these days, as far as I know, are mandated to be developed with a Database as the data store. It would seem to me that rdms is just as, if not more, efficient as me writing code to manage data in the file system. Not to mention less error prone. I think a database setup is much more scaleable...especially in the web environment. For example, if the server hosting the webpage gets upgraded to a webfarm, then I'll run into major synchronization issues. The datastore would have to get moved to a fileshare...I'll stop there. Thinking about that scenario makes my head hurt:) I don't want to get into an argument about data housing theory, because for maintanence issues, I'll probably always use a database. Mainstream its easier for someone to maintain and understand a rdms, than to come in and maintain custom code. Isn't a rdms nothing more than an elegant file system?

>I understand normalization pretty well. So don't take what follows the
wrong way.
Why is normalization a good thing?

I don't take it the wrong way at all. Normalizing is not the end all solution. If this were a data warehouse project normalizing would be my worst enemy. But for this scenario, I am very interesting in Data Integrity, and normalizing is my friend. For example, a big problem (my) county websites have is that they were created by 50 million different people with 50 million different artistic ideas. So when regular Joe's need to navigate county websites, its a mess. Sometimes it's the hardest thing to find navigation. With that said, it's very important to the higher ups that everything fall within a standard look and feel. If I were to keep everything in one table, as how it was, then what is stopping each user from naming the exact same building something different, because that's how it was built to do. Like I said, I'm inheriting this, not creating it from scratch. So now, with the building entity having its own table, with just one row per building, every judge page in the same building will have the exact same building name, as opposed to whatever that staff member felt on a whim what it should be.

>I've seen worse cases than this stored all in one table. I refer you to
"Stupid Database Tricks" in this newsgroup a year or two back.

I don't know what kind of work environment the above posters are in, but I've seen some crazy stuff, especially working for the goverment, where people got nice tech jobs back in 1970 and haven't cared to upgrade their skillset but are required to work with modern technology.  Maybe its just a government thing.

Thanks for your comments. I appreciate your feedback and am enjoying this conversation. Received on Fri Mar 03 2006 - 22:35:50 CET