2010-09-27 3 views
3

Я создаю сайт 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, которые используются в структуре, описанной выше с точки зрения производительности?

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

ответ

2

Я не человек NoSQL, но мне интересно, может ли этот конкретный случай лучше всего обрабатываться с помощью базы данных документов (MongoDB или CouchDB). Различные типы объектов с прикрепленными метаданными звучат как сценарий, для которого предназначен MongoDB.

FWIW У вас есть пара проблем с вашим именем в таблице и поле, которое может вас укусить позже. Например, тип и дата являются скорее обобщенными, а также зарезервированными словами. Вы также смешивали уникальные и множественные имена таблиц, которые будут бросать любое автоматическое сопоставление объектов.

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

+0

Я обновил свой первый пост вопросом о NoSQL, спасибо. – pt2ph8

0

Или вы можете сохранить содержимое объекта в виде файла за пределами базы данных, если вас беспокоит пространство базы данных.

Если вы храните что-либо в базе данных, у вас уже есть тип объекта в objects; поэтому вы можете просто добавить таблицу object_contents с длинным двоичным полем для хранения объекта. Вам не нужно создавать новую таблицу для каждого нового типа.

+0

Я должен уточнить, что мне действительно не нужно хранить фактическое видео или файл песни, вместо этого метаданные будут состоять только из строк и ints - вот почему таблица с этими дополнительными данными казалась более естественной для меня. – pt2ph8

0

Я видел много JOIN в веб-приложении реального мира (от 5 до 10). Таблица объектов может быть большой, но для этого нужны индексы. До сих пор я не вижу ничего плохого в вашей базе данных. Кстати, что для меня было странно - один пост, один объект и отдельные комментарии для каждого? Нет возможности смешать картинки с текстом?

Смежные вопросы