Subject:
|
Re: A Technic set DB outline
|
Newsgroups:
|
lugnet.admin.database
|
Date:
|
Mon, 30 Nov 1998 04:15:31 GMT
|
Viewed:
|
607 times
|
| |
|
|
Larry:
Thanks for your comments, this is exactly the type of
discussion I hoped posting this would generate:
>
> Disclaimer: I am not a DBA but I do know enough SQL to be dangerous.
> Interesting. I comment on this as if it were a logical DB design. Do
> you have a downloadable schema (for erwin or whatever?)
>
> Some comments:
>
> Is recno designed to get round the set number not being unique? I'd
> prefer to see it called "set ID" or similar.
Yes.
>
> Theme table seems empty.
It is. I am still trying to figure out how to put themes and subthemes
into a table.
>
> MinifigTable. Will this just index into images. For Technic that's fine,
> but for real minifigs it may be better to model the parts separately, so
> a minifig is comprised of a torso, arms, legs, hands, head, hairpiece,
> etc.
>
> Also, the dates are derived data. Drop them. Instead, have the sets
> reference minifigs via a minifig-set association table, This then allows
> you to derive the intro and disco dates.
This makes alot more sense than my approach.
>
> Set Table.
> What do the indexterms in the set table do?
The index terms are my idea of terms like, helicopter, auto chassis, etc.
The lego names by themselves seldom indicate what the model exactly is. I
envisioned doing searches like show me all of the forklift models between 1977
and 1885, e.g.
> I would rather see the set names in a separate table. 8 fields is too
> many for most
Actually this is currently my biggest problem, how do you model the data for
1. A set with different numbers and different names
2. a set with the same number and different names
3. a set with different numbers and the same name
etc.
> Are the intro and disco dates by "model year"? How do you capture mid
> year intros? For a set stated to be available Jun 99, do you put in May
> because that's when it was orderable from S@H??
I am considering just year, not month/year, because I dont have month/year
information on most early Technic stuff, and sets tend to have different
month intoductions depending on where you are.
> Both the element and minifigs need to be done with intermediate
> associations.
> Color is totally derivable from elements if modeled correctly, unless
> this is noting the "sense" of the model color.
The elements table is designed to include only the most specialized of
the specialized elements (like motors, RCX's, pneumatic elements) and color is
a very general indicator (e.g color; red/black, gray) of the model.
> Instructions should be a separate table instead of carrying three slots.
>
> I feel this is a very good start!
again, thanks for your comments
Jim
hughesj@one.net
|
|
Message has 1 Reply:
 | | Re: A Technic set DB outline
|
| First off, let me state that were I designing this from scratch I'd do an object model not a data model but... (...) You need a hierarchy table. Model it like this (not legit SQL) Table Theme ThemeID integer PRIMARY KEY NOT NIL ThemeType Code /* (...) (26 years ago, 30-Nov-98, to lugnet.admin.database)
|
Message is in Reply To:
| | Re: A Technic set DB outline
|
| Jim Hughes wrote: Disclaimer: I am not a DBA but I do know enough SQL to be dangerous. Interesting. I comment on this as if it were a logical DB design. Do you have a downloadable schema (for erwin or whatever?) Some comments: Is recno designed to (...) (26 years ago, 30-Nov-98, to lugnet.admin.database)
|
9 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Database
|
|
|
|
|
|
