#sql #database #database-design #content-management-system
#sql #База данных #проектирование базы данных #content-management-system
Вопрос:
Я разрабатываю концептуальную схему для базы данных SQL, которая будет обрабатывать записи, помогающие профилировать определенный набор пользователей. (Вы можете себе представить, что я разрабатываю для шпионского агентства, которое создает портфолио на членов организации).
Меня беспокоит то, что коллекция документов, используемых для составления профиля этих людей, постоянно растет. Я хотел бы включить функциональность, подобную CMS, для пользователей уровня управления, которые могли бы определять общий документ в веб-интерфейсе, который служил бы средством ввода дополнительной информации в базу данных. Это было бы аналогично набору листа бумаги «заполните пробелы» и предоставлению копий для добавления (по мере необходимости) к существующим тематическим файлам.
Уместно ли продолжать добавлять новую таблицу в базу данных для каждой записи, которая стала необходимой?Я опасаюсь разработки веб-приложения, которое будет генерировать новую таблицу для каждого типа документа, особенно если новые типы документов будут регулярно изобретаться. Я был бы признателен за любые мысли по этому вопросу. Я предоставил свою альтернативу, модель сущностей-отношений, которая, как я полагаю, может позволить создавать общие типы документов и создавать последующие тематические записи с использованием определенных типов документов. Я также был бы признателен за любую критику этой альтернативы.
Этот подход определяет ЗАПИСЬ как ДОКУМЕНТ, относящийся к определенной теме. ДОКУМЕНТ определяется с использованием набора пользовательских DOCUMENT_FIELDs, которые основаны на определяемом системой наборе ПОЛЕЙ. ЗАПИСЬ заполняется с использованием RECORD_DATA, которые являются абстрактными контейнерами для данных, которые идентифицируются их RECORD_ID (внешний ключ), а также специфичным для документа DOCUMENT_FIELD (также внешний ключ).
Мое главное сомнение в отношении этого дизайна заключается в том, насколько громоздким будет для разработчиков программного обеспечения доступ к записям и содержащимся в них данным.
Комментарии:
1. Я не думаю, что это правильный путь для будущего. Я думаю, ваша формулировка / терминология мне не нравятся. Вы утверждаете, что помимо основной информации о человеке, такой как имя, идентификатор, дата увольнения и т. Д., У вас в конечном итоге будут пользовательские метаданные, такие как избранный фильм, возраст и т. Д.? Итак, вы ищете способ настроить таблицы данных для будущих метаданных? Если это так, просто создайте основную таблицу и пользовательскую таблицу. Основная таблица будет содержать основную информацию о человеке, а пользовательская таблица всегда будет указывать на основную таблицу, но позволит вам добавлять связанные с ней мета / пользовательские атрибуты
2. @JonH : В будущем, безусловно, появятся пользовательские метаданные. Эти данные существуют в коллекциях, которые, безусловно, требуют использования уникальных таблиц («Табель успеваемости», «Свидетельство о рождении», «Водительские права», «Описание контактных линз» и т.д.). Спасибо за ваши комментарии по этому поводу, я думаю, что пользовательские атрибуты значительно уменьшат сложность.
3. такая схема будет ужасно сложной, и кто может сказать, что она когда-нибудь закончится? Я предполагаю, что если табель успеваемости станет отдельной таблицей, как вы будете обрабатывать отношения с этим типом данных, поскольку они управляются метаинформацией и различаются для каждого человека. Я больше думаю о том, что вы, возможно, делаете слишком много в своем приложении. Я бы действительно просто создал то, что я упомянул, и создал дополнительную таблицу для хранения «Вложений», поэтому у человека может быть несколько вложений, которые могут быть простыми файлами, такими как PDF табеля успеваемости.
4. Мне нравится идея перемещения документов в архив, подобный вложениям, когда содержащиеся метаданные вряд ли будут задействованы в сложном запросе. Спасибо за ваши мысли по этому поводу.
5. Думайте об этом как о своей собственной википедии по предмету. Даже википедия должна где-то остановиться, она содержит информацию, скажем, об актере. В нижней части статьи Википедии приведены ссылки (вложения / указатели у вас есть) на метаданные, которые хранятся на других сайтах. Таким образом, хотя данные не хранятся непосредственно в схеме Википедии, они могут ссылаться на дополнительную информацию из других источников. Это то, что должна делать ваша система, иначе вы пытаетесь сделать слишком много сразу…