Re: Data Model

matthewdavis1980_at_hotmail.com wrote:
> 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.

I just looked at the current Court 11 page and it seem much like a boiler plate page with some links to jurisdictional pages. Although a court has many different people associated with it, those roles are consistent for every court and something like ...

Court[Number, Address, JudgeName, ClerkName, etc, etc]

... would suffice. Alternatively you could go to ...

Court[Number, Address] --> Person[Emp#, Name, Tel] --> Role[RoleName]

... but adds little for the web page as it stands.

(Note the PK and FK's are implied for brevity by the arrows)

Of course with some of the requirements expressed since your initial post this would need to be extended beyond the single table.

> 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.

Note - my comments purely relate to the page as it is today.

> 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.

Its never that foolproof, and whilst I am an adherent, I also try to avoid building any edifice to future requirements if they haven't been expressed by the business yet. Sure, if they say "when that is done we want to move on to ...." that is different - then you should do some analysis to ensure you will be prepared.

> 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.

Not offense taken - just remember the art is balancing the delivery of todays requirements whilst positioning to be able to sustain the same rate of productivity in the future.

> 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.

I agree - performance won't be an issue.

> 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.

I haven't investigated first hand but there some open source ones - Mambo I think is rated, although its pedigree is subject to some corporate machinations FWIR.

> Theory has served me well, but common sense and simplicity are my best
> friends in practice.

KISS.
> Remember, there was a time you couldn't even type

Still can't! :-)

> good thing you've taken a few theory classes since then.

Not for a looong time!

Cheers, Frank. Received on Sat Mar 04 2006 - 05:36:18 CET