Beautiful. Thanks! BenO At 05:00 PM 7/7/02 -0500, you wrote: > >The tables will be used to enable users to enter comments concerning what > >they believe happens at individual conjunctions. For example, in astrology, > >let's say one enters a comment of what happens when the Moon enters > >Scorpio. These comments can then be called by other users and rated with an > >accreditation system similar to Amazon's rating of books (and those who > >rate them). > > > >The problem occurs with granulation. Let's say, instead, that our above > >example is when the Moon enters Scorpio while the Sun is in the fifth > >degree of Aries and Mars is in the twentieth degree of Gemini while the > >natal chart reflects that this nativity has an ascendant at the seventh > >degree of Cancer, etc. Indeed, it's actually far more involved than that, > >because I'd like to cross-reference other metaphysical systems (Tzolkin, I > >Ching, etc.) several of which have nativities as well as transient > >elements. I can see tables literally in the thousands (or much higher) with > >no way to avoid this proliferation. Any suggestions? > >Ok, here's one way I see to organize this: > >First, create a table with all the possible single events (e.g >"moon enters Scorpio") (is varchar(100) enough for the description?) >and an artificially created event ID (id int not null auto_increment >primary key). > >Next, create a table for all the combinations (it is probably more >appropriate here to create entries for combinations actually USED, >not all possible combinations, as a table for all possible combinations >may rapidly exceed the amount of disk storage ever manufactured). >I am not sure what you'd need here beyond just a combination ID, but >there might be some kind of composite rating of the event. > >Next, create a table to relate events to combinations (a many-to-many >relationship). This combination happens when this event, that >event, and a third event happens. This table has two columns, >event ID and combination ID, and lists the events that make up a >combination. For example, if a combination C happens when three >events, X, Y, and Z happen, then you'd have three rows: > > Event ID Combination ID > X C > Y C > Z C > >The combination (event ID, combination ID) should be unique. > >Now, create a table for the people making comments. This would >include a commenter ID (primary key), some kind of text name for >that person, and possibly a password they use to make comments >under their name. This might include an email address and billing >information. > >Next, create a table for the comments. This contains a combination ID >for what they are commenting on, the commenter ID, and the comment made. > >Ok, that's 5 tables. I can't see the number of tables growing even >if astrology suddenly discovered 27 more planets and 5 new signs of >the zodiac. The contents of the tables would get bigger, but >there wouldn't be more of them. > >I'm not that familiar with Amazon's rating system so I can't comment >on what additional tables are needed for that. > >You'd need a SQL query with a multi-way join to get the description of >the combination, the commenter name, and the comment made, but >this shouldn't be hard or slow with appropriate indexes on the tables. > > Gordon L. Burditt > >--------------------------------------------------------------------- >Before posting, please check: > http://www.mysql.com/manual.php (the manual) > http://lists.mysql.com/ (the list archive) > >To request this thread, e-mail <[EMAIL PROTECTED]> >To unsubscribe, e-mail ><[EMAIL PROTECTED]> >Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
--------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
