Subject:
|
Re: Unique keys for sets
|
Newsgroups:
|
lugnet.admin.database
|
Date:
|
Tue, 28 Dec 1999 16:15:38 GMT
|
Viewed:
|
2614 times
|
| |
|
|
In lugnet.admin.database, Remy Evard writes:
> > Would it possible and reasonable to add a unique key to the Pause
> > database setlists?
>
> But... hm. A possible problem with documenting the key is that the
> unique key used in the Pause database appears to change over time.
No, the primary keys in that DB haven't changed since they were first created
in April of 1998.
When the DB is reborn out of its current form and into its new form, the old
keys will be obsolete, but there will be a backward compatible facility to
make sure that old links still work.
> If TLC were to come out with another set numbered 8880, what would
> the keys be for the sets?
> I'm guessing, based on evidence on the db pages, that the Supercar's
> unique key would become 8880-1, while the new set would be assigned
> a key of 8880-2.
Yup! In the current incarnation of the DB, it would be given the key
"8880-2", meaning the second issuance of the set number 8880. In future
incarnations, the primary keys are random 40-bit integers, with secondary
keys being set numbers. (So those unsightly "-1"s and "-2"s will eventually
go away.)
> A change like that might be fine internal to Pause
> (I don't know) but would confuse personal databases like mine, and
> probably result in misdirected links and associations from other
> web sites that had been pointing at 8880, not 8880-1.
Well, actually, adding a second 8880 as 8880-2 isn't actually changing any
numbers. 8880 doesn't exist in the DB as "8880" -- it actually exists as
"8880-1". Anything linking to
http://www.lugnet.com/pause/search/?query=8880
was never actually linking to the first 8880 set. In fact, it was never
pointing at any set -- it was simply pointing at a query for any set ID
beginning with "8880" (of which there simply happens to be only 1 result).
(Note the text at the top that says "1 match for '8880'" on that query.
The canonical URL for the first 8880 set in the Pause DB is
http://www.lugnet.com/pause/search/?query=8880-1
So adding a second 8880 as "8880-2" would give the URL of
http://www.lugnet.com/pause/search/?query=8880-2
and there's really no problem, and the first one with just plain "8880" would
still work, only it would pull up two results now instead of just one.
> One option would be to use the year as part of the key. I think Kevin
> does something like this on Brickshelf, and it's part of what I have
> been doing in my spreadsheet. It doesn't quite solve the problem of
> what to do if there are more than one set with the same number in one
> year (like set 1974 or 214), but maybe TLC has stopped doing that... :-)
Welp, the main problem with years in a large DB of sets is that the years
are not always known, and, as it turns out, by and large, most of the
duplicate set numbers are actually in the very low numeric ranges back in
the 60's and 70's, where information is particularly sparse. Another
problem of practicality is that the year of release of some set can "change"
(it doesn't really change, of course :-) when new info is turned up. For
example, it was once thought that 493 was a 1979 set. Later, someone turned
up a copy of an instruction book dated 1978.
> Dang... I didn't plan to ask for something and then disagree with
> myself... I haven't been paying much attention to the online Lego
> community until fairly recently, but I would guess that the subject
> of unique, unchanging set keys came up ages ago. Has this problem
> already been generally solved?
There's really no good "solution" in which the primary keys involve set
numbers. Here's where I'm heading, BTW, WRT primary keys for the sets DB:
http://www.lugnet.com/db/brictionary/?n=39
Of course, those are purely internal unique keys, not intended to be seen
by humans. The nice thing is, 99% of sets are identifiable by a single
secondary key (the set number), and of the remaining 1%, more than half of
those are identifiable by an additional tertiary key (the year), and the
remainder are (hopefully) identifiable by an additional quaternary key (the
theme). So in practice, 99% of the links will still require only a single
set number, although additional parameters could always optionally be used.
--Todd
|
|
Message has 1 Reply:
 | | Re: Unique keys for sets
|
| Todd, I guess what several of us want is for those keys (regardless of whether they should be seen by humans or not) to appear in the Pause listings. Many (?) of us use the Pause listings to generate tables in our own databases and then use that for (...) (25 years ago, 28-Dec-99, to lugnet.admin.database)
|
Message is in Reply To:
| | Re: Unique keys for sets
|
| A few minutes ago, I posted: (...) But... hm. A possible problem with documenting the key is that the unique key used in the Pause database appears to change over time. If TLC were to come out with another set numbered 8880, what would the keys be (...) (25 years ago, 27-Dec-99, to lugnet.admin.database)
|
12 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
|
|
|
|
|
|
