|
| |
|
|
| |
для: Qiao
(08.05.2009 в 06:39)
| | | для второго запроса потребуется еще
ALTER TABLE `tagsnews` ADD UNIQUE KEY (`tag_id` , `news_id`) ; | |
| |
|
|
| |
|
|
| |
для: Trianon
(08.05.2009 в 01:41)
| | | Я сделал
ALTER TABLE `newstags` ADD PRIMARY KEY ( `news_id` , `tag_id` ) ;
Ссылка интересная по теме:
http://www.c2.com/cgi/wiki?FearOfAddingTables | |
| |
|
|
| |
|
|
| |
для: Qiao
(07.05.2009 в 14:25)
| | | >SELECT id_news WHERE id_tag=$id
Для этого запроса нужен индекс на поле id_tag, либо составной уникальный индекс на полях id_tag, id_news
>SELECT id_tag WHERE id_news=$id
Для этого запроса нужен индекс на поле id_news, либо составной уникальный индекс на полях id_news, id_tag
В принципе, можно сделать два составных индекса (один из которых назначить первичным ключом) | |
| |
|
|
| |
|
|
| |
для: Qiao
(07.05.2009 в 14:25)
| | | Здрасти. А добавлять строки в таблицу святым духом будете? | |
| |
|
|
| |
|
|
| |
для: Trianon
(07.05.2009 в 14:02)
| | | Запросов тут может быть только два:
SELECT id_news WHERE id_tag=$id
SELECT id_tag WHERE id_news=$id | |
| |
|
|
| |
|
|
| |
для: Qiao
(07.05.2009 в 13:04)
| | | зависит от характера и частоты запросов... | |
| |
|
|
| |
|
|
| |
для: Trianon
(07.05.2009 в 12:48)
| | | Просто уже молоточек зашлифовал - REGEXP '.*\[^\\d\]?$tagID\[^\\d\]?.*'
Красота )
Но вы убедили - буду таблицу делать.
Даже не столько ради производительности, столько для того, чтобы попробовать теорию на практике. А там, глядишь, привыкну.
А что, кстати, оптимальней (по производительности) - делать id или составной ключ? | |
| |
|
|
| |
|
|
| |
для: Qiao
(07.05.2009 в 12:34)
| | | "Сижу с шурупом и молотком у стены и думаю, как лучше начать - то ли шуруп молотком забить (быстро), то ли за отверткой сходить (медленно, но держаться лучше будет)."
Пля. | |
| |
|
|
| |
|
|
| |
для: Qiao
(07.05.2009 в 12:23)
| | | А Вы можете этот столбик id не создавать вообще.
А перичный ключ составным сделать (по двум живым полям) | |
| |
|
|
| |
|
|
| |
для: cheops
(07.05.2009 в 12:17)
| | | Хотя я вот вашу же цитату в соседней теме прочёл:
> Существует только два фундаментальных способа оптимизации обслуживающего кода и баз данных: чтобы было удобно программистам (скорость разработки) и машине (скорость вычисления). Начинают с первого способа, если не хватает мощности, переходят ко второму.
Если так судить, то мне легче с регулярными работать, да и база в близжашем будущем будет маленькой.
Однако в вашей цитате не учтена стоимость "перехода". Ведь если я захочу перейти к третьей таблици ради оптимизации, то придётся попотеть, тобы создать таблицу из строчки и преобразовать обслуживающий код.
Поэтому меня сейчас терзают сомнения как лучше начать - регулярками или нормализацией. | |
| |
|
|
|
