Data Model
matthewd...@hotmail.com
There are many Judges.
There are many Buildings.
There are many Locations inside buildings( such as floors ).
Each judge must reside at exactly one location.
A staff member has a name, phone number, and email.
Each judge has 6 staff members, one of each type: Clerk, Assistant
Clerk, Coordinator, Bailiff, and Court Reporter.
How would you model this scenario?
Thanks, I'm looking forward to seeing the different results.
Gene Wirchenko
So is your instructor.
Sincerely,
Gene Wirchenko
matthewd...@hotmail.com
I actually have this work project finished and am working with someone(
professionally ) who does not understand normalization. I wanted to
put this simple scenario out and see what everyone would come up with.
If I have posted this in the wrong group and need to be redirected to
another group then by all means let me know. Thanks for ruining this
little exercise and contributing something positive.
BTW, Here is the "Biggest D*ckhead" award. You've won it by a
landslide. I hope one day I can be like you.
matthewd...@hotmail.com
Forgot to mention, first week on the job and I inherited this
application. The developer I'm working with had all of this in 1
table.
I didn't put this info out there because I didn't want to see responses
that would get off topic.
matthewd...@hotmail.com
that would get off topic. But if it makes you feel better and
convinces you to have an intelligent conversation, so be it.
Pickie
suspect you are not "on the job".
"Each judge must reside at exactly one location"
is language that would be used in an acedemic exercise, not about a
real judge.
Frank Hamersley
> It's not a 'real world' example, so it's not an application, and I
> suspect you are not "on the job".
>
> "Each judge must reside at exactly one location"
>
> is language that would be used in an acedemic exercise, not about a
> real judge.
True - a circuit judge it seems is not needed for first year projects at
least.
> matthewd...@hotmail.com wrote:
>
>>Gene,
>>
>>Forgot to mention, first week on the job and I inherited this
>>application. The developer I'm working with had all of this in 1
>>table.
Now that is "Pure Bullsh!t". Even the most unskilled labourer would
have more than 1 table. After the obvious tables, it requires a bit
more knowledge.
>>I didn't put this info out there because I didn't want to see responses
>>that would get off topic. But if it makes you feel better and
>>convinces you to have an intelligent conversation, so be it.
One week on the job - Lesson 1 - click once only to post!
Cheers, Frank.
matthewd...@hotmail.com
Thanks for your responses. I work for the government and recently
transfered to this position. If you don't believe that it was all in
one table believe it. I know it seems far fetched, but its really how
it was.
We'll, here is the URL to the website I am redoing. See for yourself.
The project is a redo of the website, and management wants the judges
support staff to update their content.
For specifically for the scenario I've provided:
http://www.justex.net/civil/11/
>It's not a 'real world' example, so it's not an application, and I
>suspect you are not "on the job".
>"Each judge must reside at exactly one location"
Notice - 301 Fannin, 2nd Floor. <-- Thats the building/location.
Sorry if it was "academic language", but I wan't to be as clear and
concise as possible.
Each <tr><td></tr></td> section of text was a field in the table. I've
came in and normalized, but that's REALLY how it was when I got here.
I don't come to these groups often and if most people in these groups
are very far beyond this and I'm wasting time, so be it. I do not know
proper "Google Group" etiquette. But I was really hoping to see what
random people would come up with, but nevermind that now.
And if this project is not considered a "real world" application, sorry
I'm not as priviledged as you in my project environment, but to me any
"real world" application pays the bills, and let me tell you, it's real
enough for me.
BTW, you can take that Bullsh!t and dance in it. I do understand you
guys probably get some academics in here who want you to do their work
for them so I'm sorry I got so defensive.
David Cressey
<matthewd...@hotmail.com> wrote in message
news:1141340176.8...@v46g2000cwv.googlegroups.com...
I'll cut you a little slack, and believe you when you insist that this is
NOT an academic exercise.
First, go to www.databaseanswers.org and see if there's a model in there
for court scheduling.
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.
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.
Fourth, why do you want to use a database? Are you trying to solve a
problem that files won't solve?
David Cressey
<matthewd...@hotmail.com> wrote in message
news:1141347455.0...@u72g2000cwu.googlegroups.com...
> Gene,
>
> I actually have this work project finished and am working with someone(
> professionally ) who does not understand normalization. I wanted to
> put this simple scenario out and see what everyone would come up with.
> If I have posted this in the wrong group and need to be redirected to
> another group then by all means let me know. Thanks for ruining this
> little exercise and contributing something positive.
>
wrong way.
Why is normalization a good thing?
> BTW, Here is the "Biggest D*ckhead" award. You've won it by a
> landslide. I hope one day I can be like you.
>
You'll go far, and I hope soon.
David Cressey
"Frank Hamersley" <terabit...@bigpond.com> wrote in message
news:DDVNf.903$z03...@news-server.bigpond.net.au...
> Pickie wrote:
> > It's not a 'real world' example, so it's not an application, and I
> > suspect you are not "on the job".
> >
> > "Each judge must reside at exactly one location"
> >
> > is language that would be used in an acedemic exercise, not about a
> > real judge.
>
> True - a circuit judge it seems is not needed for first year projects at
> least.
>
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.
matthewd...@hotmail.com
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.
Carl Federl
There are many Judges.
There are many Buildings.
There are many Locations inside buildings( such as floors ).
Each judge must reside at exactly one location.
A staff member has a name, phone number, and email.
Each judge has 6 staff members, one of each type: Clerk, Assistant
Clerk, Coordinator, Bailiff, and Court Reporter.
How would you model this scenario?
>
With a lot of questions:
May two staff members have the same name ?
May two staff members have the same phone number ?
May two staff members have the same email?
What identifies a staff member ? Social Security Number, State
Employment ID ?
May a staff member not have a phone ? e.g. waiting for a phone to be
installed or not yet known.
Same for question for staff email.
May a staff member exist that is not assigned to a judge ?
May a staff member be shared between two judges ?
What are the attributes for Judges - do they have a name ? Phone ?
email ?
When a Judge is no longer active (retires or not re-elected) , what
happens to the staff ? Are they all assigned to the replacement Judge
?
Do you need a history of what staff members worked for what judge.
Senario: Assistant Clerk is promoted to Clerk and is assigned to a new
Judge. Do you need to know when they stopped working for the old judge
?
Is there a concept of Courts ? see
http://www.justex.net/civil/civilcrt/civil.htm
Are the Court Types ? Civil, Criminal, Family ...
Are staff assigned to Courts or to Judges ?
Frank Hamersley
> Hi all,
>
> Thanks for your responses. I work for the government and recently
> transfered to this position. If you don't believe that it was all in
> one table believe it. I know it seems far fetched, but its really how
> it was.
At the time I struggled to imagine how someone could make it so hard for
themselves - masochism perhaps.
> We'll, here is the URL to the website I am redoing. See for yourself.
> The project is a redo of the website, and management wants the judges
> support staff to update their content.
>
> http://www.justex.net/
>
> For specifically for the scenario I've provided:
>
> http://www.justex.net/civil/11/
Having looked at the site I can now appreciate why a single table was
used. Are there shared officers between judges? If not in fact a
single table is adequate - in fact you don't even need a database FWICT
- just some html with a CMS!
[..]
> BTW, you can take that Bullsh!t and dance in it. I do understand you
> guys probably get some academics in here who want you to do their work
> for them so I'm sorry I got so defensive.
No problem with that - the "theory" component is oft replaced with
"practice".
Cheers, Frank.
matthewd...@hotmail.com
Excellent questions!
>May two staff members have the same name ?
Of course
>May two staff members have the same phone number ?
No - but open for debate
>May two staff members have the same email?
Nope
>What identifies a staff member ? Social Security Number, State
Employment ID ?
Anything you want, but in this case a staff member is more a position.
I think I could have worded that better.
>May a staff member not have a phone ? e.g. waiting for a phone to be
installed or not yet known.
Some will never get phone numbers.
>Same for question for staff email.
Some will never get email.
>May a staff member exist that is not assigned to a judge ?
Nope, back to the position thing. You can't have a position without a
judge/court to serve.
>May a staff member be shared between two judges ?
Technically no, politically, anything goes :)
>What are the attributes for Judges - do they have a name ? Phone ?
email ?
Judges have name and "court" phone number.
>When a Judge is no longer active (retires or not re-elected) , what
happens to the staff ? Are they all assigned to the replacement Judge
?
Position ( staff ) is assigned to court, once again, I should have set
this up a little better.
>Do you need a history of what staff members worked for what judge.
Senario: Assistant Clerk is promoted to Clerk and is assigned to a new
Judge. Do you need to know when they stopped working for the old judge
?
No, just who is working the current position is all that is relevant.
>Is there a concept of Courts ? see
http://www.justex.net/civil/civilcrt/civil.htm
Bingo, on that page, each court is assigned a number, which is in front
of the judge name.
For example, Judge Mark Davidson serves the 11th court.
>Are the Court Types ? Civil, Criminal, Family ...
Yes. Better language for court types is open.
>Are staff assigned to Courts or to Judges ?
Courts, one last time, I could have described the scenario better :)
Carl, these are excellent questions. I appreciate your thought
process.
matthewd...@hotmail.com
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 @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
Frank Hamersley
> 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.
David Cressey
<matthewd...@hotmail.com> wrote in message
news:1141443096.1...@z34g2000cwc.googlegroups.com...
> 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.
>
PMFJI.
For years, I have been really enthusiastic about Ralph Kimball's Star
Schema design for building a multidimensional model projected onto the
SQL-RDM. I would still recommend it as a possible design choice for anyone
building a Db where OLAP takes precedence over OLTP. For OLTP, I'd prefer
a more normalized design.
If you take a close look at a Star Schema, it's really only a few steps
removed from the "one big table" concept. It removes all of the dimensional
attributes from fact tables, and replaces them with a foreign key to a
dimension table. But it's really almost one big table.
So much so, that it's easy to build a view of a star schema that shows it
as one big table, and then do all your queries as subsets of that one big
view. Not necessarily the best implementation, but great for prototyping.
matthewd...@hotmail.com
@Frank
You are definately right about things not being bullet proof...but I'm
not going to walk into a fight with Mr. T with one hand tied behind my
back :-)
>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.
With this job, I'm about 50% developer and 50% solution provider. Part
of my job is to be the one that 'offers' solutions and upgrades to
existing processes, as opposed to just getting a project and doing it
to a certain specification. With that said, I have to try my best to
set my self up for success in the future, and still achieve a rapid
level of deliverables. By no means am I going to go off on a tangent
trying to prepare for every possible scenario, but if I set things up
as entities and relationships that closely match the business model I'm
a little more flexible in my options to not have to code a hack. Thats
where common sense steps in.
>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.
And just for giggles, Harris County has an enterprise wide agreement
with Microsoft, the open source killer. I was at the Information
Technology center and built a cms from the ground up. It's really nice
and has been accepted by users...but top management wants a package for
everything, so I was tasked to build something until the next budget
cycle came through incase they didn't get approval. They( we up until
this week ) have narrowed it down to 2 vendors and my cmp. Many think
the cmp is enough and purchasing a package is a waste of money,
considering the cmp as it is now covers 95% of users needs, is stable,
and performs extremely well. What I've learned about these package
systems is that they are great, but cost mucho dinero.
So I've transferred over and these guys I'm with now ( All of this as
it has been told to me ) have been burned badly by site server. To
elaborate, what they've tasked my with is getting everything
"mainstream". If I were to suggest open source they would throw me out
the window :-)
Thanks for your data model, this is what I came up with. Feel free to
shoot it down if you disagree.
PK's are defined by *
FK's are defined by #
CK's are defined by &
The relationships are implied. I may have forgot a few fields but the
main structure is there.
tblJudge[ *JudgeID, JudgeName, PhoneNum, #CourtClassID, #LocationID ]
tblCourtClass[ *CourtClassID, CourtClass ] --Civil, Criminal, etc...
tblBuilding[ *BuildingID, BuildingName, Address, City, State, Zipcode ]
--Harris County Civil Courthouse
tblLocation[ *LocationID, #BuildingID, Location ] --9th floor
tblStaffType[ *StaffTypeID, StaffType ] --Secretary, Clerk, Bailiff,
etc...
tblJudgeStaff[ &JudgeID, &StaffTypeID, StaffName, PhoneNum, Email ]
This was finalized before Carl asked his questions, so to address Carl:
I merged the Court and Judge entities as one entity. Great questions.
I could have easily replaced the word Staff with Position or something
similiar. Once again, excellent questions. Thanks for asking
questions and getting down to the bottom of things. I'm very curious
as to how you would model this, knowing its for a web environment.
I know that technically, this could have been normalized more, but I
think it matches the business model and isn't overkill. Some people
would probably go less, others would probably go more. THAT is EXACTLY
what I came here to find out.
@David
Interesting information. I agree your with views. If this website was
getting a lot of hits I probably would have preferred a OLAP style of
design for the data store. Functionally, OLAP and OLTP data stores
implementation should be transparent to my consuming app, and I've
designed it that way.
@ALL
BTW...where is my good buddy Gene???? What does he have to say? I'm
interested in all points of view, and as many as possible.
B Faux
Please forgive the naivety, but you say you're working for the government...
you apparently have not discovered that the last thing you want to do is
actually *fix* anything. Best case is go for job preservation and move up
the food chain so you can dump your crap on the next junior that comes
along.
So much for the free advice...
>
> 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.
>
IMHO, if you don't expect to run query's against it, you don't need a DB.
Look at Wiki's
Peter Theony's is pretty good: www.Twiki.org - loads fast, runs good, has
version control, update control (to keep judge #1 away from judge #2's
stuff) and can be loaded on M$ servers as well as *nix servers.
Doesn't cost a thing to use, as long as you don't sell anything...government
and all.
Just an idea...
BFaux ;-)
Pickie
At the time, I thought you were someone who was trying to 'get their
homework done'. I was wrong.
I think you need a table of "Judges"
another one of "Persons"
another one of "Locations"
the problem you face is that "Locations" is nothing to do with
"Buildings"
if you try to model Buildings, you are going to have a problem. This
is not part of your 'problem space'. it's a concept you 'drug' into
your real poblem. Don't try to solve other people's problems.
The best answer I can give is that you should actively look to minimise
your 'problem space'
Pickie
Pickie
matthewd...@hotmail.com
That is good stuff, but unfortunately management wouldn't go for
something like that. Either Microsoft or nothing at all. I do like
your idea of moving up the government latter, but unfortunately I can't
help but do the best I can, for my own benefit....so, no crap from me.
Matt
matthewd...@hotmail.com
No problem...I understand where ya'll were coming from.
I added the building in because all "locations(floors)" in a building
have the same address, city, zip, etc...
This way the user can select a building and view all available
locations. I don't see this changing often, but I feel future
enhancements that will use this data will benefit from this design.
I agree, I did drag this into my problem, and I can't just let it go :-)
Gene Wirchenko
>No problem...I understand where ya'll were coming from.
>
>I added the building in because all "locations(floors)" in a building
>have the same address, city, zip, etc...
The building that I live in has four addresses. I am not
counting suite numbers as different. The three businesses on the
ground floor are at 1313, 1315, and 1317. The apartments on the
second floor have 1313 1/2. (Yes, that one half is really there.)
Some buildings facing on more than one street even have different
street names in their different addresses. I recall reading an
article in "Byte" oodles of years ago that was on an arson program and
the difficulties they had in determining which addresses applied to
which buidlings.
>This way the user can select a building and view all available
>locations. I don't see this changing often, but I feel future
>enhancements that will use this data will benefit from this design.
Look out.
>I agree, I did drag this into my problem, and I can't just let it go :-)
Be careful. That feeling of power might be self-electrocution.
<G>
Sincerely,
Gene Wirchenko
matthewd...@hotmail.com
Thanks for your feedback. I agree with your assesment, and if I was
writing something that needed a more robust addressing system I
probably would have designed this accordingly. Fortunately for me
court buildings do not get nearly as complex as other address/building
scenarios. In a way, I know the building table could just as easily
been named an address table, and different addresses could have the
same building name, but be different rows...but that's getting of on a
tangent for my scenario, and what I have now will suffice and keep me
open to work arounds within future requests for the website.
In the future though, for my own sake, I would appreciate more feedback
than just "Look out". If "Look out" refers to your reasoning above
such as different addresses in the same building, then please ignore my
last statement. If it refers to something else I might not be seeing,
then please, by all means fill me in. I like to expand my mind.
>Be careful. That feeling of power might be self-electrocution.
Who would have ever thought sticking a spoon in a power outlet could be
so bad. :-(
@Everyone
The civil courts section is up. The folks move into their brand new
building Monday. Not bad for two weeks on the job in goverment work :)
For you web tech junkies it's running under the .Net framework 2.0.
The site master template is a powerful tool I must say.
The main site and how it's always been can be found here:
-Navigate to the courts section ( http://www.justex.net/court.htm )
-Click "Civil" to go to my redesigned area that is pulling content from
my db. I also provided tools so the staff can add pages to "their"
area and edit them with a WYSIWYG rich text editor. That stuff is in
the bottom section of each judges page, just under the "Court Staff"
section. Click each link to see the "AMAZING" stuff people come up
with.
http://www.justex.net/new_civil/Courts/Civil/CivilCourts.aspx
-View the other courts, such as criminal, to see the old layout if you
haven't seen it before.
Thanks everyone, and by all means view my data model and rip it to
shreds. It's post number 14 in this thread.
Thanks,
Matt
P.S. Found the other developer who had it all in one table is very
competent and understands normalization quite well. <-- Not being
sarcastic.
Barbara
matthewd...@hotmail.com wrote:
> Gene,
>
> Thanks for your feedback. I agree with your assesment, and if I was
> writing something that needed a more robust addressing system I
> probably would have designed this accordingly.
There is a draft Data Model that corresponds to your requirements on
this Page :-
http://www.databaseanswers.org/data_models/judges_and_courts/index.htm
It shows a Normalised Database design with one table
('Consolidated_View') which has all the data in one Table.
HTH
B.Dimple
Senior DBA
matthewd...@hotmail.com
Thanks for your reply. That's a pretty nifty website.
I'm trying to understand if the model provided is a situation, when
implemented, where all of those tables exist? For example, is the
"Consolidated View" a "View" of the normalized tables, or is the
"Consolidated View" the only table that exists, but fields are left out
of the model image for brevity sake?
Here is a question for the DBA's, if this model is what I think it is,
about the Inner workings of sql server. If the "Consolidated View" is
in fact a view of the full relational model, does this view get cached?
When a relevant field is updated or row added, does this view execute
and re-cache itself? This may be a very basic question and I'm know I
could dig into the documentation and find this answer, but I'm curious
as to what DBA's in practice know about this scenario. I know it's
getting away from theory and no one has to answer it, but I'm just
curious.
Thank you for your effort. I really appreciate it.
Matt
Gene Wirchenko
[snip]
>In the future though, for my own sake, I would appreciate more feedback
>than just "Look out". If "Look out" refers to your reasoning above
>such as different addresses in the same building, then please ignore my
>last statement. If it refers to something else I might not be seeing,
>then please, by all means fill me in. I like to expand my mind.
I *ended* my feedback with "Look out". Be very wary of thinking
that you have a situation totally scoped out and the solution to end
all solutions. The Real World has a tendency (compulsion?) to make
solutions obsolete.
[snip]
Sincerely,
Gene Wirchenko
matthewd...@hotmail.com
Right on! I know I'll never have an end all solution and thats a good
thing...it's what keeps us employed. With that said, my goal is to get
as close as I can...and for this scenario, it's good enough.
Thanks,
Matt
topmind
> I have a situation:
>
> There are many Judges.
> There are many Buildings.
> There are many Locations inside buildings( such as floors ).
> Each judge must reside at exactly one location.
> A staff member has a name, phone number, and email.
> Each judge has 6 staff members, one of each type: Clerk, Assistant
> Clerk, Coordinator, Bailiff, and Court Reporter.
>
> How would you model this scenario?
>
I'll give it whirl:
Table: Person // or perhaps "Employee"
-------------
person_id
person_role // judge, clerk, assistent, etc. (see note)
name
phone
etc...
table: Location
---------------
locat_id
building_ref // f.k. to Building table (not shown)
locat_descript
etc...
table: Locat_group
------------
locat_ref // f.k. to Location table
person_ref
Now for the endless caveats:
Some might propose a different table per employee or person "type",
such as a Judge table, Bailiff table, etc. I never liked such
approaches. For one, people can and do change roles and it is easier to
flip a role flag than delete and re-add. Plus, "types" often results in
having to use verbose UNION queries to do the same thing to the
different employee types, which is ugly, inefficient, and repeatative.
It is also possible in practice for a person to have multiple roles,
such as after budget cuts. Further, a given person may be say a Clerk
in one room and an Assistent in another. For simplicity sake, I am
ignoring that possibility.
This approach does not enforce six and only six positions per location
(room), at least not without extra logic. If the goal is to keep things
flexible, it is often a bad idea to hard-wire a fixed set of slots into
schemas. Many-to-many tables, such as the Locat_group table above
allows such flexibility for future changes. However it may complicate
the immediate needs to build such flexibility into the system before it
is actually needed.
If you want to better enforce the "six" rule and avoid many-to-many
tables, then perhaps make a Courtroom table:
table: Courtroom
-----------
crt_room_ID
crt_descript
building_ref // f.k. to Building table (not shown)
judge_ref // f.k. to Person table
clerk_ref // f.k. to Person table
assist_ref // etc...
coordntr_ref
bailiff_ref
reporter_ref
In such a case, we may not need the "role" column in the Person table
because having an ID in the slots of the Courtroom table supplies that
info instead. Further, it allows one to be different roles in different
rooms. However, keep the "role" column if you don't want that feature.
And perhaps we don't need the Location table either, since the
Courtroom table can serve that purpose instead. However, it cannot be
used to track storage rooms, administrative offices, etc. It creates
the same kinds of "one-table-per-type" problems that the employee types
suggestion above did.
But if your system is to only focus on courtrooms, then other types of
rooms may not be your concern. You may want to bring up the issue of
consolidation with other room-tracking systems, though. It will show
them that you are forward-thinking. Just don't insist on it if the
customer is not interested. A mild suggestion is sufficient.
In such designs, one is often faced with the tradeoff of short-term
versus long-term. Satisfying immediate needs may make development
simpler up front, but in the longer run somebody 12 years down the road
will cuss their heads off at you if you take the short road and stick
them with the kludgy patchwork needed to make static slots or
category-specific tables into a more flexible system. However, you may
be long gone and don't care anymore. There is something to be said for
"time discounting" from the financial world, where one knocks off about
15% per year of the cost of a given decision. In other words,
"discount, but don't entirely ignore the future".
-T-
matthewd...@hotmail.com
Great post. After being out in production for a little while, some
courts have requested extra types of staff, so it worked out pretty
easily to just add another row to my stafftype table. They have also
requested two staff of the same type for one court, because both staff
members work the same position part time. A request by my boss has
been made already to extend this data store to applications outside of
the website. They want to use the staff part of it to be a centralized
store for employee phone numbers and etc...so pretty much the rule of
exactly only 6 types of staff for each court has been thrown out the
window. The new rule is, you have any type of staff available to you,
you pick and choose what you want. The above changes are exactly what
I was expected to a certain degree, and it will be/was easy to pull
them off, without having to hack and write an obscure work around.
If I had kept this all in one table I would have been screwed.
Thanks for your time and post,
Matt
topmind
Matt,
Glad to hear it is working out okay.
Note that I prefer to use the word "roles" here rather than "type"
because roles tend to be based on set-theory, where-as "types" are more
hierarchical. A given person can potentially belong to many roles.
However, "types" tend to assume or imply a one-and-only-one selection
from a list or tree of options. One "has-a" role(s), but "is-a" type.
Just a linguistical pet-peve of mine.
Take Care,
-T-
Neo
> There are many Buildings.
> There are many Locations inside buildings( such as floors ).
> Each judge must reside at exactly one location.
> A staff member has a name, phone number, and email.
> Each judge has 6 staff members, one of each type:
> Clerk, Assistant Clerk, Coordinator, Bailiff, and Court Reporter.
>
:) I am pretty sure you were not looking for results as different as
this, but here it is to tickle your mind.
The script below populates an experimental db with the following
persons: Judge Judy (phone# 333-5555, email j...@aol.com &
judg...@law.com) who has following staff members: Clerk Clark (who
has Assistant Ashley), Coordinator Colby, Bailiff Brandy and
Court-Reporter Courtney each with various properties. Building
CourtHouse1 has two floors. The first floor has room1. The second floor
has room1 and room2. Various person are placed in different parts of
CourtHouse1. The sample query (near end of script) finds a staff member
of a judge whose assistant has a certain phone#. Data can be easily
navigated when viewed in a tree just by clicking nodes (even though the
underlying data doesn't necessarily have a tree structure); where as in
RM, it will require one to join multiple tables. If requested, I can
email the populated db/exe (188 kb zip file) so one can see for
themselves. Note, it is a prototype so other features may not work.
Note, I did not make bi-directional relationships (ie j...@aol.com emailOf
judy) to keep the example simple. One effect of creating bi-directional
relationships would have been to allow user to effectively "walk up"
any relationship while expanding tree nodes. Note, script expressions
become more elaborate when dealing with multiple things with the same
name.
Unlike RMDBs, where one must first design a schema/structure to hold
anticipated data, no schema is required before entering data in the
experimental db. The reason is, it already starts with a very general
schema that is capable of modelling most anything in a normalized
manner. This is partially why unanticipated types of data can be added
on the fly during execution without a design/compile phase. Db
automatically normalizes data and maintains referential integrity.
Other constraints, such as each person must have a phone number or 6
staff members, need to be implemented at code level where as RMDBs can
implement such basic constriants at db level.
// Create a type named building.
(create type instance (new))
(create (it) name (findElseAdd name instance 'building'))
(create dir item (it))
// Create a type named floor.
(create type instance (new))
(create (it) name (findElseAdd name instance 'floor'))
(create dir item (it))
// Create a type named room.
(create type instance (new))
(create (it) name (findElseAdd name instance 'room'))
(create dir item (it))
// Create a type named person.
(create type instance (new))
(create (it) name (findElseAdd name instance 'person'))
(create dir item (it))
// Create a type named judge.
(create type instance (new))
(create (it) name (findElseAdd name instance 'judge'))
(create dir item (it))
// Create a type named staffMember.
(create type instance (new))
(create (it) name (findElseAdd name instance 'staffMember'))
(create dir item (it))
// Create a type named clerk.
(create type instance (new))
(create (it) name (findElseAdd name instance 'clerk'))
(create dir item (it))
// Create a type named assistant.
(create type instance (new))
(create (it) name (findElseAdd name instance 'assistant'))
(create dir item (it))
// Create a type named coordinator.
(create type instance (new))
(create (it) name (findElseAdd name instance 'coordinator'))
(create dir item (it))
// Create a type named bailiff.
(create type instance (new))
(create (it) name (findElseAdd name instance 'bailiff'))
(create dir item (it))
// Create a type named courtReporter.
(create type instance (new))
(create (it) name (findElseAdd name instance 'courtReporter'))
(create dir item (it))
// Create a type named phone#.
(create type instance (new))
(create (it) name (findElseAdd name instance 'phone#'))
(create dir item (it))
// Create a type named email.
(create type instance (new))
(create (it) name (findElseAdd name instance 'email'))
(create dir item (it))
// Create a verb instance named has.
(create verb instance (new))
(create (it) name (findElseAdd name instance 'has'))
// Create a person/judge named Judy.
(create person instance (new))
(create judge instance (it))
(create (it) name (findElseAdd name instance 'judy'))
(create (it) phone# (findElseAdd phone# instance '333-5555'))
(create (it) phone# (findElseAdd phone# instance 'JDG-JUDY'))
(create (it) email (findElseAdd email instance 'j...@aol.com'))
(create (it) email (findElseAdd email instance 'ju...@law.com'))
// Create a person/staffMember/clerk named Clark.
(create person instance (new))
(create staffMember instance (it))
(create clerk instance (it))
(create (it) name (findElseAdd name instance 'clark'))
(create (it) phone# (findElseAdd phone# instance '737-5588'))
// Create a person/staffMember/clerk/assistant named Ashley.
(create person instance (new))
(create staffMember instance (it))
(create clerk instance (it))
(create assistant instance (it))
(create (it) name (findElseAdd name instance 'ashley'))
(create (it) phone# (findElseAdd phone# instance '737-5588'))
// Create a person/staffMember/coordinator named Colby.
(create person instance (new))
(create staffMember instance (it))
(create coordinator instance (it))
(create (it) name (findElseAdd name instance 'colby'))
(create (it) email (findElseAdd email instance 'co...@msn.com'))
// Create a person/staffMember/bailiff named Brandy.
(create person instance (new))
(create staffMember instance (it))
(create bailiff instance (it))
(create (it) name (findElseAdd name instance 'brandy'))
(create (it) phone# (findElseAdd phone# instance '919-9945'))
// Create a person/staffMember/courtReporter named Courtney.
(create person instance (new))
(create staffMember instance (it))
(create courtReporter instance (it))
(create (it) name (findElseAdd name instance 'courtney'))
(create (it) phone# (findElseAdd phone# instance '203-9898'))
(create (it) email (findElseAdd email instance 'c...@gov.org'))
// Create judge judy's staffMembers.
(create judy staffMember clark)
(create judy staffMember ashley)
(create judy staffMember colby)
(create judy staffMember brandy)
(create judy staffMember courtney)
// Create Clark's assistant Ashley
(create clark assistant ashley)
// Create a building instance named CourtHouse1.
(create building instance (new))
(create (it) name (findElseAdd name instance 'courtHouse1'))
// Create a floor instance named floor1
// and make it part of courtHouse1.
(create floor instance (new))
(create (it) name (findElseAdd name instance 'floor1'))
(create courtHouse1 has (it))
// Create room instances named room1
// and make it part of floor1.
(create room instance (new))
(create (it) name (findElseAdd name instance 'room1'))
(create floor1 has (it))
// Create a floor instance named floor2.
// and make it part of courtHouse1.
(create floor instance (new))
(create (it) name (findElseAdd name instance 'floor2'))
(create courtHouse1 has (it))
// Create room instances named room1
// and make it part of floor2.
(create room instance (new))
(create (it) name (findElseAdd name instance 'room1'))
(create floor2 has (it))
// Create room instances named room2
// and make it part of floor2.
(create room instance (new))
(create (it) name (findElseAdd name instance 'room2'))
(create floor2 has (it))
// Create CourtHouse1's has reporter Courtney.
(create courtHouse1 has courtney)
// Create CourtHouse1's floor1's has Ashley.
(create (relElem (select courtHouse1 has floor1))
has
ashley)
// Create CourtHouse1's floor1's room1 has Clark.
(create (relElem (select (relElem (select courtHouse1 has floor1))
has
room1))
has
clark)
// Create CourtHouse1's floor2's room2's has Judge Judy.
(create (relElem (select (relElem (select courtHouse1 has floor2))
has
room2))
has
judy)
// Find a staff member of a judge
// whose assistant has phone# 737-5588.
// Displays clerk Clark.
(msgbox (and (select (select judge instance *) staffMember *)
(select * assistant (select * phone# 737-5588))))
JOG
> > There are many Judges.
> > There are many Buildings.
> > There are many Locations inside buildings( such as floors ).
> > Each judge must reside at exactly one location.
> > A staff member has a name, phone number, and email.
> > Each judge has 6 staff members, one of each type:
> > Clerk, Assistant Clerk, Coordinator, Bailiff, and Court Reporter.
> >
> > I'm looking forward to seeing the different results.
>
> :) I am pretty sure you were not looking for results as different as
> this, but here it is to tickle your mind.
I wonder if the OP's mind has ever been tickled with a sledgehammer
before?
Neo
> > this, but here it is to tickle your mind.
>
> I wonder if the OP's mind has ever been tickled with a sledgehammer
> before?
I would be interested in seeing the script for an approximately similar
RM solution. Could you post it?
JOG
Why not post such a script yourself if you want to make comparisons?
Neo
Because I'm not the one who is wondering if the OP's mind has ever been
tickled with a sledgehammer before.
JOG
I can't make much sense of this line of argument. Why would requiring
me to post an sql solution affect your post? (or would you like me to
post an xml, rdf and pick version too - my consultancy fees are
relatively cheap...)
Neo
I can't make much sense of your mean spiritedness.
> Why would requiring me to post an sql solution affect your post?
It doesn't affect mine, but posting your solution does allow you to
determine if the OP's mind has ever been tickled with a sledgehammer in
a more methodical manner that promotes constructive discussion rather
than a long exchange of tit-for-tat that leads no where.
> ... or would you like me to post an xml, rdf and pick version too ...
Select the one you feel would be most appropriate or are skilled at. I
wouldn't expect you to post a solution using a methodology that you are
unexperienced with or feel is inferior.
> - my consultancy fees are relatively cheap...)
What are your consultancy fees? Who are some of your past and present
clients? What is your area of expertise and length of experience? What
is your education history? And how much would you be charging your self
for posting a solution that is similarly flexible as mine so that you
could figure out if the OP's mind has ever been tickled with a
sledgehammer.
JOG
of your "human-mind" approach if you are so irascible.
I recommend (again sincerely) that you post a much shorter, simple
example and make a comparison with solutions from other extant
approaches (such as RM) to show why your technique is superior, as
opposed to requiring others to do that for you.
Hopefully you will, and if you do I will give it due attention, Jim.
matthewd...@hotmail.com
never seen that script before.
mAsterdam
>>- my consultancy fees are relatively cheap...)
>
> What are your consultancy fees?
Cheaper than Hugo's ?
David Cressey
<matthewd...@hotmail.com> wrote in message
news:1144336350....@e56g2000cwe.googlegroups.com...
> Does OP stand for Object Pascal? Is that Object Pascal script? I've
> never seen that script before.
>
Generally, in Newsgroups, OP means "Original Post" or "Original Poster"
matthewd...@hotmail.com
Then what does this mean?
>I wonder if the OP's mind has ever been tickled with a sledgehammer
before?
David Cressey
<matthewd...@hotmail.com> wrote in message
news:1144348097.2...@i39g2000cwa.googlegroups.com...
Sorry, I can't answer that one. I tend to take almost all subthreads that
involve Neo as coming from an alternate reality of some kind.
matthewd...@hotmail.com
involve Neo as coming from an alternate reality of some kind.
Ok, thanks for the heads up. I was wondering what all of that was
about.
Neo
The above remark made by JOG, was intended to insult the solution that
I presented to your problem. JOG carries his ill sentiments over from a
recent thread titled "Storing Code and Data in a Db with LISP-like
Interface" where I asserted that the experimental db is analogous to
using an adjustable wrench (sizes 0-20) compared to relational
methodology which is analagous to using fixed-size wrenches (1, 2, 3
... 10); and that my methodology was more applicable for some
out-of-range applications (ie size 12.34 nuts or AI-type applications).
I posted such a problem and its solution and asked other to do the same
for a comparison; however no one did and simply resorted to insults
such as "[your methodology is analogous to using] a large,
truck-mounted, diesel-powered hydraulic-actuated wrench, requiring a
skilled specialist operator and a maintenance budget that would make
the military blush". Apparently JOG has abbreviated that derogatory
description to a sledgehammer.
But I ask again, with no ill will, JOG would you post an RM solution to
the OP and model the same or similar data that I have, so that we can
compare some aspects, especially flexibility to handle changes and new
types of data.
JOG
> But I ask again, with no ill will, JOG would you post an RM solution to
> the OP and model the same or similar data that I have, so that we can
> compare some aspects, especially flexibility to handle changes and new
> types of data.
No, I'm clearly not going to do your work for you - a dodo in a
blindfold could probably have discerned that by now. I have no interest
in binary graph structures for logical modelling of information and as
such have no reason to waste my time retreading already disproven
ground.
But, as I said, I will honestly read any short comparisons you make
yourself. Perhaps you have had some epiphany that everyone else has
missed. But I doubt it.
Neo
>> the OP and model the same or similar data that I have, so that we can
>> compare some aspects, especially flexibility to handle changes and new
>> types of data.
>
> No, I'm clearly not going to do your work for you -
I am not asking you to do my work for me. I have already done so and
posted it. I am asking you to provide some tangible support for your
assertion that my solution is a sledgehammer compared to some other.
> a dodo in a blindfold could probably have discerned that by now.
Why does a professional consultant like you have to resort to
derogatory comments?
> I have no interest in binary graph structures for logical modelling of information and as such have no reason to waste my time retreading already disproven ground.
Me either. Just because someone says my solution is based on binary
graph structures doesn't mean it is true. My interest is in verifying
flexibility of the solutions, not logical models.
> But, as I said, I will honestly read any short comparisons you make yourself.
It is not my responsibility to support your assertion.
> Perhaps you have had some epiphany that everyone else has missed. But I doubt it.
It is easy enough to find out, just post a solution which models the
same data (see comments) which mine does and then we can compare their
flexibilities.
JOG
Well your suggestion analogises to a sledgehammer if naught but for its
verbosity. As others have suggested, I cannot imagine having to type
such a sprawling solution in. There is no need to post an alternative
solution for this observation to be valid.
As such, all that I can say to this Neo is that there appears to be a
clear impression of your 'model' here. If (in your opinion) we have an
incorrect understanding then (if it were me) I would think about why
this miscomprehension has occurred, reassess my delivery and attempt to
remedy the situation.
Its a sad fact of life that noone is going to get off there backsides
to help one do this. Start a new thread and convince us. But the onus
is on you.
I wish you all best and I will leave it at that, Jim.
(apologies to the Object Pascal for inadvertantly contributing to the
hijacking of this thread)
Neo
I'd suggest not being so focused initially on counting the number of
characters in an alternate solution. I'd like you to focus more on the
flexibility to model things and a solution's resiliency to
unanticipated changes.
> As such, all that I can say to this Neo is that there appears to be a clear impression of your 'model' here. If (in your opinion) we have an incorrect understanding then (if it were me) I would think about why this miscomprehension has occurred, reassess my delivery and attempt to remedy the situation.
While the probability of something being true is usually high when
everyone has a similar impression, majority opinion isn't proof in of
itself. Among other examples, at one time, nearly everyone believed
that the earth was flat.
> Its a sad fact of life that none is going to get off there backsides to help one do this.
Lets just say, it hard for them to prove to me that the world is flat.
> Start a new thread and convince us. But the onus is on you.
The name of that thread was "Storing Code and Data in a Db...". The
common impression is that I do not understand RM and incapable of using
it to create solutions, so accordingly, I can only post my solutions to
various problems and compare the results.
Had you posted a solution that handles 0 to many classification of each
persons; allows each thing (person, building, floor, room, etc) to have
0 to many properties; each property to having 0 to many values; allows
a flexible hierarchy to model the location of a person within any part
of the building, floor or room as mine solution does without a single
NULL and complete normalization; and then subjected the two solution to
handle new types of data, only then would you begin to see beyond your
preconceptions.
> (apologies to the Object Pascal for inadvertantly contributing to the hijacking of this thread)
Yes, this long tit-for-tat thread initiated by your derogatory remarks
was not very constructive.
matthewd...@hotmail.com
before thinking. I'd really like to have that one back :-)
I would appreciate if this argument did go to a new thread, but with
that said, I respect Neo for the model provided. Unfortunately it is
too far from mainstream for my bosses to even consider. I do
appreciate the other point of view though, maybe there is something to
be learned from it.
mAsterdam
JOG
> Object Pascal accepts your apology, and feels foolish about posting
> before thinking. I'd really like to have that one back :-)
I do miss my turbo pascal and delphi days though ;)
Neo
.
You are correct that my method of creating a solution is too far from
mainstream for you to consider. And I didn't offer a schema that would
hold the data modelled by my script, first because my method doesn't
require the user to specify a schema; second because the schema
required for it in RM can become impractical and may require generic
modelling. You may need the expertise of a RMDB expert to create that
schema or to tell you that it is impractical.
Because the script I posted earlier was meaning less to you, I will now
show how the data appears when viewed in the db's grid and tree views.
The grid view below only shows instances of person. The tree view
below, on the other hand, shows most of the relevant things. In order
to properly view the below data, you will need to click "fixed font"
near the top-right of web page. In essence, the tree nodes display
sentences in subject-verb-object format. In order to describe the tree
view below, I have adopted some conventions. Tree nodes representing
subjects and objects are capitalized where as verbs are not. Also the
object of the initial sentence becomes the subject of the subsequent
sentence and so on. For example, the sentences "Building instance
CourtHouse1" and "CourtHouse1 has Floor1" is displayed as the following
sequence of nodes: Building, -instance-, CourtHouse1, -has-, Floor1,
etc. Also a "+" symbol after a node indicates that it can be expanded
to that shown else where in the tree. Thus the user (even a child) can
easily navigate to all the details of various things no matter what
tree path is taken, without anybody having to join tables (and there
will eventually be many). All this is much easier to see, just by
clicking around in the small db/exe which fits on a floppy.
Grid View of Person Instances:
Note, grid only shows first value of an attribute.
ID name phone# email staffMember
-- --------- -------- ------------- -----------
# judy 333-5555 j...@aol.com clark
# clark 737-5588
# ashley 737-5588
# colby co...@msn.com
# brandy 919-9945
# courtney 203-9898 c...@gov.org
Tree View of Relevant Things:
Notice that the tree can show multiple values of an attribute. Notice
that a person can be located in a building, on a floor or in a room.
Ask the RMDB experts how they would achieve this in a normalized,
NULL-less manner.
Dir
|-item-
|-Building
| |-instance-
| |-CourtHouse1
| |-has-
| |-Floor1+
| |-Floor2+
| |-Courtney+
|
|-Floor
| |-instance-
| |-Floor1
| | |-has-
| | |-Room1+
| | |-Ashley+
| |
| |-Floor2
| |-has-
| |-Room1+
| |-Room2+
|
|-Room
| |-instance-
| |-Room1 (of Floor1)
| | |-has-
| | |-Clark+
| |
| |-Room1 (of Floor2)
| |
| |-Room2 (of Floor2)
| |-has-
| |-Judy+
|
|-Person
| |-instance-
| |-Judy
| | |-phone#-
| | | |-333-5555
| | | |-JDG-JUDY
| | |
| | |-email-
| | | |-J...@aol.com
| | | |-Ju...@law.com
| | |
| | |-staffMember-
| | |-Clark+
| | |-Ashley+
| | |-Colby+
| | |-Brandy+
| | |-Courtney+
| |
| |-Clark
| | |-phone#-
| | | |-737-5588
| | |
| | |-assistant-
| | |-Ashley+
| |
| |-Ashley
| | |-phone#-
| | |-737-5588
| |
| |-Colby
| | |-email-
| | |-co...@msn.com
| |
| |-Brandy
| | |-phone#-
| | |-919-9945
| |
| |-Courtney
| |-phone#-
| | |-203-9898
| |
| |-email-
| |-c...@gov.org
|
|-Judge
| |-instance-
| |-Judy+
|
|-StaffMember
| |-instance-
| |-Clark+
| |-Ashley+
| |-Colby+
| |-Brandy+
| |-Courtney+
|
|-Clerk
| |-instance-
| |-Clark+
| |-Ashley+
|
|-Assistant
| |-instance-
| |-Ashley+
|
|-Coordinator
| |-instance-
| |-Colby+
|
|-Bailiff
| |-instance-
| |-Brandy+
|
|-CourtReporter
| |-instance-
| |-Courtney+
|
|-Phone#
| |-instance-
| |-333-5555
| |-JDG-JUDY
| |-737-5588
| |-919-9945
| |-203-9898
|
|-Email
|-instance-
|-j...@aol.com
|-ju...@law.com
|-co...@msn.com
|-c...@gov.org