Я создаю сайт PHP/MySQL, и сейчас я работаю над своим дизайном базы данных. У меня есть база данных и опыт MySQL, но я никогда не структурировал базу данных с нуля для приложения реального мира, которое, надеюсь, будет иметь хороший трафик, поэтому я бы хотел услышать советы от людей, которые уже сделали это , чтобы избежать распространенных ошибок. Надеюсь, мои объяснения не слишком запутывают.Внедрение структуры базы данных для общих объектов
Что мне нужно
В моем приложении, пользователь должен быть в состоянии написать пост (название + текст), а затем создать «объект» (который может быть что угодно, как видео, или песня и т. д.) и прикрепить ее к сообщению. На сайте есть список предопределенных типов объектов, которые пользователь может создать, и я должен буду добавлять новые типы в будущем. Пользователь должен также иметь возможность видеть детали объекта на выделенной странице и добавлять к нему комментарий - то же самое относится и к сообщениям.
То, что я пытался
Я создал objects
таблицу с этими полями: oid
, type
, name
и date
. Эта таблица содержит записи для чего-либо, что пользователь должен иметь возможность добавлять комментарии (например, сообщения и объекты). Затем я создал таблицу postmeta
, которая содержит дополнительные данные сообщения (такие как текст, автор, последняя дата редактирования и т. Д.), Таблицу videometa
для данных о объекте «видео» (URL, описание и т. Д.) И т. Д. A postobject
стол (pid
, oid
) ссылки объекты на сообщения. Кроме того, есть таблица comments
, которая содержит текст комментария, автора и идентификатор объекта, к которому он относится.
Поскольку список типов объектов предопределен и, вероятно, не изменится (хотя мне все еще нужна возможность легко добавлять тип в любое время без изменения структуры кода приложения или дизайна базы данных), и это относительно маленькое, создать таблицу «мета» для каждого типа не составит труда и сделать соответствующий класс PHP в моем приложении для его обработки.
Наконец, страница на сайте должна отображать список всех сообщений, включая прикрепленные к нему объекты, отсортированные по дате. Поэтому я получаю все записи из таблицы objects
с типом «post» и присоединяюсь к ней с помощью postmeta
, чтобы получить метаданные сообщения. Затем я запрашиваю postobject
, чтобы получить все объекты, прикрепленные к этому сообщению, и comments
, чтобы получить все комментарии.
Вопросы
Есть ли в этом смысл? Хорошо ли создавать базу данных таким образом для сайта реального мира? Мне нужно присоединиться к нескольким таблицам, чтобы получить все нужные мне данные, а таблица objects
станет огромной, поскольку она содержит почти каждый элемент (только тип, имя и дата создания) - это сохранить базу данных и гибкий код приложения, но работает ли он в реальном мире, или это слишком дорого в долгосрочной перспективе? Думаю ли я об этом неправильно с помощью такого подхода ООП?
В частности: предположим, что мне нужно перечислить все сообщения, включая их прикрепленные объекты и метаданные. Мне нужно будет присоединиться к этим таблицам, по крайней мере: posts
, postmeta
, postobject
и {$objecttype}meta
(не говоря уже о таблице users
, чтобы получить все сообщения определенного пользователя, например). Смогу ли я добиться низкой производительности, даже если я использую только числовые индексы?
Кроме того, я рассмотрел возможность использования базы данных NoSQL (MongoDB) для этого проекта (благодаря совету Стюарта Эллиса). По-видимому, это кажется гораздо более подходящим, так как мне нужна гибкость. Но я сомневаюсь: метаданные для моих объектов включают в себя множество ссылок на другие записи в базе данных. Итак, как мне избежать дублирования данных, если я не могу использовать JOIN
? Должен ли я использовать DBRef и описанные методы here? Как они сравниваются с MySQL JOIN
s, которые используются в структуре, описанной выше с точки зрения производительности?
Я надеюсь, что эти вопросы действительно имеют смысл. Это мой первый проект такого рода, и я просто хочу избежать огромных ошибок, прежде чем запускать его и выяснить, что мне нужно полностью переделать дизайн.
Я обновил свой первый пост вопросом о NoSQL, спасибо. – pt2ph8