Subject:
|
Re: SciBrick is looking for you!
|
Newsgroups:
|
lugnet.org.scibrick
|
Date:
|
Mon, 25 Oct 2004 21:57:04 GMT
|
Viewed:
|
3969 times
|
| |
|
|
In lugnet.org.scibrick, David Eaton wrote:
| |
In lugnet.org.scibrick, Bram Lambrecht wrote:
| |
I think I might have required unique member ids on those tables too. The
idea was to keep the number of columns in sb_m down, but maybe that’s not
really necessary.
|
Depends how much space you need to save, I guess. If you’re using varchar’s
or text fields (for profiles certainly), you’re only adding an extra... 2
bytes for a null entry? Forget if it’s 1 or 2. So maybe 18 bytes extra per
member. I guess when it comes to stuff like that I rarely think about space
requirements anymore :)
|
It was more a matter of keeping the table easier to read and deal with for
things like just listing members, which doesn’t require a full bio and location,
than of actually saving bytes.
| |
| |
The zipcodes table is 40,000+ rows, while the world cities table is only a
couple hundred rows. Doesn’t make much sense to combine them, since it
would make it more difficult to add cities to the world table.
|
Yeah, there’s not terribly much benefit if you’re going to bounce the
long/lat over to the member entry anyway-- Where it would make more sense is
if you had something like:
|
| |
Member:
------------
member_id
...
location_id
...
Locations:
-------------
location_id
city
state
zipcode
country
longitude
latitude
Hence, if you ever wanted to crossref, say, an event with the
location table, it’s all there in one table. But with the
longitude latitude stored in the member entry, and the
zipcode/worldcity tables more just for lookup purposes,
it’s not as necessary.
|
The idea was to avoid lookups in those huge tables since we will never have
nearly as many members as we have locations.
--Bram
|
|
Message is in Reply To:
 | | Re: SciBrick is looking for you!
|
| (...) Depends how much space you need to save, I guess. If you're using varchar's or text fields (for profiles certainly), you're only adding an extra... 2 bytes for a null entry? Forget if it's 1 or 2. So maybe 18 bytes extra per member. I guess (...) (20 years ago, 25-Oct-04, to lugnet.org.scibrick, FTX)
|
74 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
