|
|
Posted by Daz on 10/24/06 19:31
Rik wrote:
> So, a unique book-id.
The book_id column is currently indexed, and was the first column I
added a primary index to.
Rik wrote:
> But uid & bookid combined are unique, create a unique index on the TWO
> columns at once.
Perhaps it's just me, but I can't quite see how I can. In the table
with containing just the usernames and user id, naturally, they are
both indexed, but on my user_books table, there is one row for each
user book. Therefore, if a user has 300 books, there are 300 rows for
that user. Also, for book_id. If more than 1 user has the same book,
then the book_ids are no longer unique either.
Sorry for not understanding what you mean.
Rik wrote:
> Why not add more? With the right indexes, searching will still be fast. You
> could even add a foreign key constraint to cascade deletions. You will not
> get null-values...
By 'Why not add more?', I assume you mean columns? Perhaps I am missing
something, but it would mean I'd have to search the book id in multiple
columns, as well as know how many columns there are at any on time, and
their names. I think it would make things far too complex. Also, I
don't understand how you could avoid null values or redundant data, as
if the user doesn't have a book, the column would be set to either NULL
or '0' which would make it redundant as it' not necessary.
I had my database organised like this previously when I first created
it a few months back when I was learning MySQL, (as I still am). But
soon realized that the database was using more space than needed, and
it was a really pain having to search every single column.
Rik wrote:
>Daz wrote:
> > The only other option I have, is to create a table for each book. That
> Brrr, do not do that :-)
Yeah, I definitely agree with you there! :D
Many thanks for your time.
Daz.
Navigation:
[Reply to this message]
|