 | | Re: SciBrick is looking for you! —Bram Lambrecht
|
| | | (...) It is a fairly easy job, just somewhat tedious. Well, the goal was to use the (URL) template engine> to completely separate style from content. (...) I am...here's the database structure I came up with (with a couple notes): (URL) file> As you (...) (20 years ago, 25-Oct-04, to lugnet.org.scibrick, FTX)
|
| | | |
| | | | | Re: SciBrick is looking for you! —David Eaton
|
| | | | (...) 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)
|
| | | | |
| | | | | | Re: SciBrick is looking for you! —Bram Lambrecht
|
| | | | (...) 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! —David Eaton
|
| | | | (...) 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! —Bram Lambrecht
|
| | | | (...) 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)
|
| | | | |
