|
|
 | | Re: SciBrick is looking for you!
|
| Sorry for prolonging this, but a few things in the post below trouble me. I have no vested interest in Sci-Brick, nor do I have a specific problem with any of the parties involved, but when I detect illogic, and stated aims in disparity with actions (...) (20 years ago, 26-Oct-04, to lugnet.org.scibrick)
| | | | | Re: SciBrick is looking for you!
|
| (...) 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 idea was to avoid lookups in those huge tables (...) (20 years ago, 25-Oct-04, to lugnet.org.scibrick, FTX)
| | | | | 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)
| | | | | Re: SciBrick is looking for you!
|
| (...) 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. (...) The zipcodes table is 40,000+ rows, while the world cities table is only (...) (20 years ago, 25-Oct-04, to lugnet.org.scibrick, FTX)
| | | | | Re: SciBrick is looking for you!
|
| (...) I might suggest combining sb_m, sb_m_loc, and sb_m_profile into sb_m, and just not fill in the _loc and _profile bits unless either supplied or member is a "full" member. Unless people can have multiple locations and profiles... Also, you (...) (20 years ago, 25-Oct-04, to lugnet.org.scibrick)
|
|
