[Shacs] database structure question.. this one is easy
Bronius Motekaitis
bronius.motekaitis at gmail.com
Wed Feb 25 11:20:16 CST 2009
Just to close the gap on this part: You've got the right understanding here,
but the issue is that while it's true that most times a given court's case
will be heard by a given judge at a given physical location, that stuff does
change frequently (mainly location). Providing for this possibility is
important, but making it mandatory to select (or rather associate) a judge
and location with a court at time of defining a specific trial would be
undue burden on the end-user.
The difference in "dummy records" cluttering Court and "default values
always used" in the Court_Default table is that specifically this purpose is
what the Defaults table is for-- they won't be dummy records, they are
seed/default values.
-bronius
On Wed, Feb 25, 2009 at 10:46 AM, Jeremy Binkley <binkleyj at gmail.com> wrote:
> It just seems to me like you are making two tables for information that can
> be handled in one. I'm not sure what court system you are making this for,
> but for the most part, judges are assigned to a specific court. Courts are
> assigned to a specific location. Etc... You mentioned you are concerned
> about having to make dummy entries in the Court table, but won't you have to
> do the same in the default table if a court has more than one location?
>
> Again, it may not be a good idea to listen to the maritime lawyer on
> matters such as this.
>
> Jeremy
>
>
> On Wed, Feb 25, 2009 at 10:12 AM, Hartness, Ken <CSC_KTH at shsu.edu> wrote:
>
>> An external defaults table has one drawback. Changes to the actual tables
>> of judges, etc., may not be reflected naturally in the defaults table.
>> Personally, I think associating an extra frequency/probability field with
>> entries would be a cool way of handling it. Just select the max or sort
>> them into a drop-down list.
>>
>> Note: didn't have time to view the models considered, so I don't know
>> what I'm talking about. Later.
>> --
>> Ken T. N. Hartness, Ph.D.
>> Computer Science Undergraduate Advisor
>> Sam Houston State University
>> ________________________________
>> From: shacs-bounces at shsu.edu [shacs-bounces at shsu.edu] On Behalf Of
>> Fuermann, Jason [JBF005 at shsu.edu]
>> Sent: Wednesday, February 25, 2009 9:41 AM
>> To: 'Bronius Motekaitis'; shacs
>> Subject: RE: [Shacs] database structure question.. this one is easy
>>
>> For the list to see. Also I guess I should have noticed you were
>> populating the trial/hearing table, I was thrown off by the naming schema on
>> the first example. I promise to pay more attention next time.
>>
>> From: Fuermann, Jason
>> Sent: Wednesday, February 25, 2009 9:11 AM
>> To: 'Bronius Motekaitis'
>> Subject: RE: [Shacs] database structure question.. this one is easy
>>
>> Shouldn’t your second example have
>> judgeid,locationid,requiredcount,trialduration in the court table as well.
>> Either way, the extra table is the way to go.
>>
>> From: shacs-bounces at shsu.edu [mailto:shacs-bounces at shsu.edu] On Behalf Of
>> Bronius Motekaitis
>> Sent: Wednesday, February 25, 2009 8:54 AM
>> To: shacs
>> Subject: [Shacs] database structure question.. this one is easy
>>
>> Let's consider the tables: Hearing, Court, Judge, and Location (notice the
>> CAPS: I did that so I wouldn't scare away any Access fans and undergrads..!)
>>
>> A Hearing can hear any Court's cases at any Location by any Judge, so
>> these are all foreign keys on Hearing. When creating a Hearing, I want to
>> populate default values for Judge, Location and a handful of other values
>> not shown here based on the Court selected.
>>
>> Where should I attach these default values? Does it make more sense to
>> make a "Court_Default" table or stuff the given Court table with these
>> foreign key values as defaults?
>>
>> See attached for comparison of the two models considered..
>>
>> -bronius
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shsu.edu/pipermail/shacs/attachments/20090225/4239c582/attachment.html
More information about the Shacs
mailing list