| |
In lugnet.loc.uk, Richard Franks writes:
> [...]
> Going back to the database idea, mainly for curiousity, and also because
> if you ever wanted to implement something like the shop information for
> /loc/us/ then it could soon become impractical to edit manually. I don't
> think that there is *that* much manual editing required for the UK,
> although we do have 4 levels as opposed to the 3 in /loc/us/, but mainly
> because there isn't as much data to be sourced.
>
> Could you define a database like:
> http://www.lugnet.com/loc/uk/?d=shops
I like that line of reasoning -- and the "d=<name>" format is also perfect
for specifying a database name as it allows for any number of named databases,
just as "n=<num>" allows for any number of numbered news articles, "p=<name>"
allows for any number of named pages, and "m=<id>" allows for any number of
member IDs.
> Would it be feasible (with editing priviledges), and assuming the data was
> sorted alphabetically, to maintain that simple shopping database like:
>
> -=-=-=-
> [/loc/uk/sc/lo/edb/?p=happy, "Happy Toys, Morningside"],
> [/loc/uk/sc/lo/edb/?p=tru, "Toys R US, Some Retail Park"],
> [/loc/uk/sc/sc/gl/?p=beatties, "Beatties, St Enoch"],
> [/loc/uk/sc/sc/gl/?p=toystack, "Toystack, St Enoch"],
> [/loc/uk/sc/sc/gl/?p=tru1, "Toys R US, Forge Retail Park"],
> [/loc/uk/sc/sc/gl/?p=tru2, "Toys R US, Queen Street"],
> [...etc...];
> -=-=-=-
I'll hafta zencogitate on this for a few days.
> So that in /loc/uk/, you could have something functionally equivalent to:
> {Shops in this Area} <</loc/uk/?d=shops&q=/loc/uk>>
>
> and in /loc/uk/sc/lo/,
> {Shops in this Area} <</loc/uk/?d=shops&q=/loc/uk/sc/lo>>
Since the new website restructuring earlier in the year, I've wanted to have
everything be more channel-based -- not like the "channels" buzzwords in the
web industry, but like lanes on a wide road... The idea is that, as a user
browsing the system, you could "be" in one "lane," and browse around, and
then switch to a different lane and browse around more from that angle. The
lanes would be things like: news, faqs, members, databases, etc.
So I would probably make "?d=shops" (or some other more general name) be a
full-fledged "lane" or "channel" in the system, where the "shops" database
occurred throughout (i.e., site-wide). In other words, "?d=shops" wouldn't
be specific to the /loc/uk/ hierarchy, but if you were in that area, then
that's what subset of it you'd see. So the URLs would actually come out
simpler, like this:
All shops in Lothian http://www.lugnet.com/loc/uk/sc/lo/?d=shops
All shops in Scotland http://www.lugnet.com/loc/uk/sc/?d=shops
All shops in the UK http://www.lugnet.com/loc/uk/?d=shops
All shops in the world http://www.lugnet.com/loc/?d=shops
Once you started browsing shops, the "?d=shops" portion of the URL would
automatically stay there until you switched to some other channel (or lane
or database)
It could work similarly for LEGO sets,
All Islanders sets http://www.lugnet.com/pirates/islanders/?d=sets
All Pirates sets http://www.lugnet.com/pirates/?d=sets
All LEGO sets http://www.lugnet.com/?d=sets
(These would just be simple browsing-based access mechanisms into the
databases; there could still be fancier mechansisms, of course, for doing
more complicated queries and merging trees and things like that.)
All LEGO sets with http://www.lugnet.com/?d=sets&q=truck
"truck" in the name
Anything in the any http://www.lugnet.com/?d=*,q=truck
database with "truck"
I think this could be a pretty powerful organizational tool for many types
of data, especially if it had optional fuzzy categories, because it combines
RDBMS, OODBMS, and HDBMS paradigms all into one.
> There are a couple (!) of issues with this:
> + An i= parameter would be nice to specify the search index
Yup -- like "n=" in the news database gives a specific numeric index, "i="
could give a specific named- or numeric-ID index. "q=" will probably always
stay as a fuzzy "query" search (not exactly an index).
Makes me wonder if the "p=xxx" stuff should go instead as "d=yyy&i=xxx".
That would generalize things nicely. Along that line of thought, the news
stuff "n=xxx" _could_ even go instead as "d=news&i=xxx" (but probably with
automatic transparent URL rewriting for backward compatability).
The spotlight stuff could work nicely as "d=spotlight", whereby the following
would happen almost for free:
Auction spotlight http://www.lugnet.com/market/auction/?d=spotlight
Pirates spotlight http://www.lugnet.com/pirates/?d=spotlight
Scotland spotlight http://www.lugnet.com/loc/uk/sc/?d=spotlight
UK spotlight http://www.lugnet.com/loc/uk/?d=spotlight
Everything spotlight http://www.lugnet.com/?d=spotlight
> + A database management file would probably also be useful, specifying any
> template page to put the retrieved information into, index names etc
Yeah, this is probably exactly what to head toward. I grok you and totally
agree. Now I just need to go zen in a cave for 3 days and think about the
details of the general implementation more.
> + Techically possible to have a database 'file' and 'entry' box in normal
> page editing. Allowing you to create a new page whereever and
> automatically include it in the database - frilly but non-vital.
Kind of like the index.html paradigm... :-)
> + It would be nice to be able to do something like:
>
> http://www.lugnet.com/loc/uk/sc/lo/?d=/loc/uk/shops&q=/loc/uk/sc/lo
>
> Then be able to edit the /loc/uk/shops database, but only see the relevant
> items to the part of the hierarchy that you were in.
Yup -- except the URL would probably be like this instead:
http://www.lugnet.com/loc/uk/sc/lo?d=shops
and right from there, if you had editor privs to that area, you could make
the changes right from your web browser.
> So I think a database would be nice, because then you can do searches
> without trawling through the entire hierarchy. Oh, and also because things
> like the 'Local Shops' link could be automated. I'm not going to plague
> Todd to implement one though - I'm just throwing ideas around :) But if
> he'd like a hand..
I think you've just set off a positive thought-chain-reaction in my brain,
which is helping make a few previously hazy design-gaps much more clear.
(Thanks!)
> Besides, we can do about 90% of the things we've discussed as soon as we
> get someone able to edit /loc/uk/!
Yea, even with the current interactive editing system that available right
now, you could do quite a bit. It's got a tiny bit of a learning curve, and
still has some fussy quirks, but it's pretty easy to get used to, I think.
> I'm in danger of sounding sycophantic if I say exactly how cool I think
> this whole mechanism sounds!
Well, I'm glad to hear it. I'll take it to mean that I'm probably still
on the right track... :-)
> > In the "true database" sense, yeah, it's in the more distant future.
>
> Ooops, I forgot reading that :) Oh well, there shouldn't be too much harm
> in discussing it?
No, not at all...in fact, it's all 50% clearer to me now...(thanks again).
--Todd
[followups to lugnet.admin.database]
|
|
Message is in Reply To:
 | | Re: Unified UK Lego community idea
|
| (...) Great! Somehow that doesn't sum it up, but it is quite lovely to read that! (...) Wow, that sounds more than reasonable! (...) I'd be happy to do it - it sounds like fun :) But I don't want to step on anyones toes, especially as there are (...) (25 years ago, 30-Nov-99, to lugnet.loc.uk, lugnet.org.us)
|
37 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Database
|
|
|
|
|
|
