Динамическое создание таблиц в БД

[vlastachu]

Здравствуйте!
Сразу к делу)
Всем известная ситуация: На сайте есть контент который делится на категории.
Самое очевидное решение: В БД поле category, исходя из которого формируется select запрос.

Но предположим в каждой категории очень много контента? Как быть? Ведь как-то не рационально получается, что СУБД будет обходить лишние поля. Много лишних полей.

Моё решение:
Средства php позволяют создавать таблицы и для каждой новой категории создавалось новая таблица.
Но моё чутьё не подсказывает, что это "чёрное" решение и к тому же в рамках yii мне сложно представить как это реализовать. Да и я как-то не встречал нигде такого решения...

Ваши мысли?

ПС я на самом деле вполне ещё новичёк и такое ощущение, что таким вопросом ни один я задавался... Как будто есть что-то очень простое по этому поводу... Но даже абстрактно ничего кроме создания новых таблиц я представить не могу.

[samdark]

Как-то так:

Код: Выделить всё

content
---------
id
categoryId
name

category
----------
id
name

[vlastachu]

Видимо обходить весь контент это нормально.

Ну ладно, раз уж тема создана то ещё по БД:

Вот есть к примеру таблица "личные сообщения", которая формируется из id,from_id,to_id,msg
И можно изначально добавить туда поля from_name,to_name
Или же при каждом выводе сообщения пользоваться join-ми
Что быстрее?

[Tokolist]

vlastachu вам необходимо почитать о нормализации БД, тогда вы сами дадите ответы на свои вопросы

[slavcodev]

Конечно же JOIN это дополнительная нагрузка на БД. Лучше один раз при сохранении сообщения найти имя по ИД, чем делать это каждый раз при чтении.

[vlastachu]

Разве скорость СУБД и нормализация БД близкие темы? ну во всяком случае спасибо!)

mc-bear, вдвойне спасибо)

[Tokolist]

Разве скорость СУБД и нормализация БД близкие темы? ну во всяком случае спасибо!)

В вашем случае да Вам необходимо найти компромисс между "дублирование данных" и "производительность", если я вас правильно понял

Нужны только внешние ключи from_id, to_id. Каждый раз заносить в таблицу с сообщениям логины юзеров не правильно, имхо.

Кроме того может потребоваться выводить еще и некоторое другие данные о юзере из таблицы Юзеры. Будете снова добавлять столбцы в таблицу ПМ?

[vlastachu]

Что же выбрать? скорость или нормальность?)

Вот заносится оно в БД явно не долго. (видимо тут несколько другой смысчл у слова "заносить")
А если вывод то 2 аспекта:
1. сам по себе вывод будет не долгий, особенно по сравнению с join выводом (здесь не моё мнение))
2. увеличивается общий объём таблицы ну и кол-во полей прямопропорционально времени операций над таблицей (рассуждение, без подтверждений!)
Но учитывая, то что выше было косвенно сказано мол объём таблицы не так важен. То можно предположить, что и здесь это подойдёт.
Блин...мысли как-то путаются... всем доброй ночи!

[slavcodev]

Нужны только внешние ключи from_id, to_id. Каждый раз заносить в таблицу с сообщениям логины юзеров не правильно, имхо.
Кроме того может потребоваться выводить еще и некоторое другие данные о юзере из таблицы Юзеры. Будете снова добавлять столбцы в таблицу ПМ?

Если мое сообщение интерпретировали не верно, я немного уточню. Ключи from_id, to_id - обязательны. Чтоб в последствии связать данные пользователя с отправителем.
А дальше набор полей в таблице скачет от необходимости. Приходится действительно выбирать, объем данных в строке либо время дополнительного запроса данных.
Если система сообщение на сайте юзается усиленно, то каждый раз таскать жойном связанные данные пользователя не правильно. Зачем насиловать БД? Ради дополнительных пару байт?
В системе сообщении насколько я понимаю, первым делом выводится список сообщений, где об авторе (from_) кроме имени и ИД (для ссылки на пользователя или кнопки ответить) ничего не надо,
и хорошо если в списке 10 сообщений, а если 100? Теперь сравниваем что правильнее (или даже не правильнее, а что лучше именно в вашей ситуации) хранить в базе два поля или делать 1000 лишних запросов?
Я бы выбрал поля.

[Tokolist]

mc-bear

Запрос будет один, а left join не так уж и сильно должен нагружать базу.
Еще возможен вариант, когда есть возможность менять юзернейм со всеми вытекающими :)

С другой стороны, если есть возможность отправлять одно ЛС сразу нескольким пользователям и при этом чтобы каждый видел кому оно отправлялось, то тут поле to_name, в котором получатели будут разделены запятой, будет необходимо.

Мой итог: Как способ оптимизации производительности такой вариант приемлем. Надо рассматривать каждый конкретный случай.

[ostin]

Я бы вопрос нормализации ставил на первое место.
Запрос с join нескольких таблиц из миллиона записей с парой десятков полей займет не так много времени, как решение проблем удобства использования, удобства разработки и администрирования, сохранности данных, гибкости и масштабируемости.
Важно создать необходимые индексы и аккуратно писать запросы. В вашем случае согласен со структурой, предложенной Sam Dark - самое классическое решение.
А при высокой нагруженности сервера помогает кеширование (запросов в базе, сгенерированных страниц, кусков кода и т.д.).
Кстати, если запрос получается очень большим (много таблиц, сложные действия над полями, нагромождение фильтров), в какой-то степени помочь может создания view (mysql 5+) для этого запроса.