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