Существует проблема наличия большого количества таблиц.
Описание проблемы на примере:
На сайте существует система опросов, опросы могут подставляться под что угодно:
1. под новость
2. под статью
3. под фотографию
4. под фотографию статьи
Все это, как понимаете, представлено различными таблицами в базе данных, соответственно и приходится данные об опросах размещать тоже в отдельных таблицах, причем каждый опрос состоит из трех таблиц (название опроса, варианты ответов, проголосовавщие по вариантам ответов).
Так получается, что получаем 4 * 3 = 12 таблиц только под информацию на одни опросы.
Можно, конечно, создать всего 3 таблицы под опросы, но для этого придётся размещать в них поле table_name, чтобы понять под новость, статью или фотографию данный опрос размещен. Но это скажется на скорости, т.к. придётся в запросе искать поле текстового вида WHERE table_name = 'new'.
II проблема.
Работа с опросами происходит одним классом. Раньше я названия таблицы опросов делал по принципу: opros + название_родительской_таблицы. Получалось что-то типа - oprosnew.
Таким принципом я руководствовался для всех подобных случаев, и в конце концов у меня просто не хватило 256 символов для названия поля таблицы
Получалось типа такого: oprosfilenfilennew. filen - это таблица с информацией о файлах, тоесть:
filennew - это текст txt новости в файле,
filenfilennew - это фотка прикрепленная под текстом новости
oprosfilenfilennew - это опрос под фоткой, которая прикреплена к новости
и так до бесконечности можно
Вообщем, это всё описание...
Помогите советом
Спустя 5 минут, 8 секунд (24.07.2009 - 10:18) Nikitian написал(а):
А я ориентируюсь на мифическую цифру: не более 1000 таблиц.
Спустя 2 минуты, 25 секунд (24.07.2009 - 10:20) AlexION написал(а):
Да, можно конечно забить на это, но когда открываешь базу и видишь кучу таблиц типа oprosfilenfilennew начинаешь думать, что что-то делаешь не так... 
Спустя 9 минут, 42 секунды (24.07.2009 - 10:30) PandoraBox2007 написал(а):
посмотри как красиво сделан опрос в phpbb пару таблиц и все готово
создай например vote_desc, vote_results, vote_voters
создай например vote_desc, vote_results, vote_voters
| PHP |
define("NEWS", 0); |
В одну из таблиц помести ее тип vote_type (SMALL INT) (news = 0; article = 1; photo = 2; photo_desc = 3) свяжи все таблицы LEFT JOIN
много таблиц тоже не хорошо особенно если эти таблицы кэшируются случается калапс когда в этих таблицах при выборке просто пусто из за лемита кеш таблиц, сделай индексы и все будет в порядке. Хотя если подумать о производительности выборки фотки и новости надо отделить по крайне мере тело.
для повышения производительности веб сервер (веб морду) отдельно, БД отдельно или кластеризировать.
Спустя 10 минут, 41 секунда (24.07.2009 - 10:41) AlexION написал(а):
Я не смотрел, но предпологаю, что в их таблицах есть поле типа: tema_id, которое ссылается на ID таблицы tema. Я же не знаю на какую таблицу идет ссылка, тоесть придется делать так:
some_id
и
table_of_some_id
Или я что-то не так думаю? все таки рекомендуете полазить в PHPBB? Если да, то подскажите сразу, как там эти таблицы будут называться, без учета префикса.
some_id
и
table_of_some_id
Или я что-то не так думаю? все таки рекомендуете полазить в PHPBB? Если да, то подскажите сразу, как там эти таблицы будут называться, без учета префикса.
Спустя 13 минут, 17 секунд (24.07.2009 - 10:54) PandoraBox2007 написал(а):
тут нужно смотреть я даже не знаю какая у тебя структура таблиц и их взаимодействия
Спустя 43 минуты, 50 секунд (24.07.2009 - 11:38) _CaXaP_ написал(а):
Я думаю Вам стоит пересмотреть сам принцип формирования таблиц...
Как вариант, сделать такие таблицы
статьи
фотки
опрос статьи
опрос фотки
варианты ответа статьи
варианты ответа фотки
ответы статьи
ответы фотки
итого 8 таблиц
А дальше делать так - если фотка находится в статье, то её нужно рассматривать всё равно как отдельную фотку из таблицы "фотки".
У Вас наверняка в тексте статьи есть какой-нибудь указатель, что в этом месте стоит картинка, для которой можно сделать опрос - вот в этот указатель и вставляйте id картинки из таблицы "фотки".
А в классе уже получайте по этому айди фотку, опрос для неё, ответы и т.п.
ЗЫ: Ответил так, как понял вопрос, может я вообще не в теме и проблема в другом :- )
Как вариант, сделать такие таблицы
статьи
фотки
опрос статьи
опрос фотки
варианты ответа статьи
варианты ответа фотки
ответы статьи
ответы фотки
итого 8 таблиц
А дальше делать так - если фотка находится в статье, то её нужно рассматривать всё равно как отдельную фотку из таблицы "фотки".
У Вас наверняка в тексте статьи есть какой-нибудь указатель, что в этом месте стоит картинка, для которой можно сделать опрос - вот в этот указатель и вставляйте id картинки из таблицы "фотки".
А в классе уже получайте по этому айди фотку, опрос для неё, ответы и т.п.
ЗЫ: Ответил так, как понял вопрос, может я вообще не в теме и проблема в другом :- )
Спустя 8 минут, 3 секунды (24.07.2009 - 11:46) sergeiss написал(а):
| Цитата (AlexION @ 24.07.2009 - 11:13) |
| Все это, как понимаете, представлено различными таблицами в базе данных, соответственно и приходится данные об опросах размещать тоже в отдельных таблицах, причем каждый опрос состоит из трех таблиц (название опроса, варианты ответов, проголосовавщие по вариантам ответов). Так получается, что получаем 4 * 3 = 12 таблиц только под информацию на одни опросы. Можно, конечно, создать всего 3 таблицы под опросы, но для этого придётся размещать в них поле table_name, чтобы понять под новость, статью или фотографию данный опрос размещен. Но это скажется на скорости, т.к. придётся в запросе искать поле текстового вида WHERE table_name = 'new'. |
На самом деле, как я это понимаю - проблема в голове того, кто придумал такую систему. Тут достаточно всего 4-х таблиц (3 из них ты указал уже):
- название опроса,
- варианты ответов,
- проголосовавщие по вариантам ответов
- описалово для опросов.
Последняя таблица (новая в этом перечне) должна содержать описание опроса и некий id, по которому будут связываться все данные по определенному опросу из разных таблиц.
И что касается скорости... "Не смешите мои подковы" (с)
Сколько там всего будет записей? Несколько десятков тысяч? Да нет проблем! При правильной индексации всё будет выбираться за доли секунды.Спустя 13 часов, 45 минут, 10 секунд (25.07.2009 - 01:31) PandoraBox2007 написал(а):
| Цитата (sergeiss @ 24.07.2009 - 08:46) |
| И что касается скорости... "Не смешите мои подковы" (с) Сколько там всего будет записей? Несколько десятков тысяч? Да нет проблем! При правильной индексации всё будет выбираться за доли секунды. |
ну не скажи там может быть сам сервер так красиво настрое что пару запросов не идет
Спустя 6 дней, 17 часов, 28 минут, 31 секунда (31.07.2009 - 18:59) AlexION написал(а):
Вообщем да, всё правильно: надо просто добавить в таблицу опросов два ключа:
1. table_type - тип таблицы, для которой задается опрос (новость, статья, фотка и т.д.)
2. field_id - ID конкретного поля этой таблицы (конкретная новость, статья, фотка...)
Но тут встает проблема:
моя админка похожа на PhpMyAdmin, плюс основана только на связях один ко многим: что позволяет быстро переходить из родителя к дочерям или из одной дочери находить родителя. А принцип двух ключей данную админку убъёт
. Конечно если опять не изобретать неведомый велосипед.
Можно конечно и так - программирование отдельных модулей для каждого раздела сайта: отдельный модуль для новостей, отдельный для статей и т.д. Прописывать для каждого модуля свой интерфейс редактирования...
Вообщем я валяюсь на диване и думаю 3-ий день
1. table_type - тип таблицы, для которой задается опрос (новость, статья, фотка и т.д.)
2. field_id - ID конкретного поля этой таблицы (конкретная новость, статья, фотка...)
Но тут встает проблема:
моя админка похожа на PhpMyAdmin, плюс основана только на связях один ко многим: что позволяет быстро переходить из родителя к дочерям или из одной дочери находить родителя. А принцип двух ключей данную админку убъёт
. Конечно если опять не изобретать неведомый велосипед.Можно конечно и так - программирование отдельных модулей для каждого раздела сайта: отдельный модуль для новостей, отдельный для статей и т.д. Прописывать для каждого модуля свой интерфейс редактирования...
Вообщем я валяюсь на диване и думаю 3-ий день