|
|
|
| Целью было создание базы запросов-ответов, причём на один запрос может быть много ответов.
Я решил делать следующим образом:
Будет три таблицы:
1. request(id, request,...)
2. sootv(id_request,id_answer)
3. answer(id, answer,...)
Тоесть в первую таблицу помещается запрос, в третью ответы на запросы (причём ответы постоянно изменяются), а во второй таблице хранятся соответствия айди-запросов айди-ответов.
И вот тут возникла загвоздка в том где и какие индексы создавать, чтобы всё работало шустро при большом количестве одновременных запросов.
Тип таблицы думаю лучше выбрать InnoDB, чтобы была поддержка вторичных ключей.
Полям id - в первой и третье таблице присвоил PRIMARY KEY, а вот дальше не пойму как правильно создать вторичные ключи (чтобы при удалении ответа удалялась и связка айди из второй таблицы со всеми упоминаниями этого ответа (ведь один ответ может быть и на несколько запросов) и по возможности (хотя это уже не так важно), чтобы удалялся сам запрос при удалении всех соответствий с айди-запроса из второй таблицы. И соответственно надо ещё как-то расставить индексы в этих таблицах...
Кроме того не понял является ли вторичный ключ индексом или его ещё раз надо создавать? | |
|
|
|
|
|
|
|
для: itica
(19.07.2009 в 15:04)
| | нет такого понятия "вторичный ключ".
У InnoDB реализована поддержка ограничения чужого ключа (foreign key constraint) если Вы об этом.
Составной первичный ключ для второй таблицы можно создать на обоих полях.
Можно также создать независимые чужие ключи с соответствующими ограничениями каскадного удаления. Связки будут удаляться.
Запрос при этом, правда, удаляться не будет , да и с чего бы ему? | |
|
|
|
|
|
|
|
для: Trianon
(19.07.2009 в 15:26)
| | Ок, понял про чужой ключ, сделал с условием, а вот составной первичный ключ не совсем понимаю что он даст (на второй таблице у меня есть щас чужой ключ айди-ответа). | |
|
|
|
|
|
|
|
для: itica
(19.07.2009 в 16:49)
| | составной ключ на полях id_req , id_answ позволяет быстро выполнять такие запросы, как
SELECT * FROM .. WHERE id_req = $req ORDER BY id_answ
первичный составной ключ на таблице связки в общем-то логичен.
Т.к. запись определяется обоими ключами. | |
|
|
|
|
|
|
|
для: Trianon
(19.07.2009 в 18:05)
| | Спасибо, разобрался... | |
|
|
|