>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
