Re: Data Model

matthewdavis1980@xxxxxxxxxxx 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 @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.
.

Relevant Pages

  • Separation of Evolution and State
    ... Intelligent Design network, inc. ... The twisted decision of the court in Dover ... one kind of "religion" - the kind that subscribes to God. ...
    (talk.origins)
  • Re: Rules of Evidence (S&T January Editorial)
    ... Azari's apparent lies to the Court about being misled by the Meade ... The 4-element Plossl eyepiece design has over decades built up a well- ... "Super-Plossl", so that you piggyback on the reputation that the real ...
    (sci.astro.amateur)
  • Re: WARNING on inventions
    ... if you want to register/Patent or Copyright a design ... if you invented it and can prove take them to court. ... American co. inc. with the law suit. ...
    (soc.culture.irish)
  • Re: question about copyrights--an innocent question not meant to start a war
    ... >> having copies of every knitting pattern ever made. ... >> you have them if anyone ever disputes that the design is your own. ... and satisfies the US court system. ... So do writers in Canada! ...
    (rec.crafts.textiles.yarn)