Разработка базы данных для системы обмена документами

Question

Я пытаюсь выяснить, хорош ли мой подход к системе обмена документами (я использую PHP и SQL).Я думаю, что я создал плохой дизайн БД.

Проще говоря, концепция состоит в том, чтобы создавать документы, делиться ими с другими, получать обновления и отзывы, используя систему комментариев.

Пользователи могут делиться своими документами с любыми другими пользователями в сети (интранет).Пользователи могут получить доступ к документам, которыми другие пользователи поделились с ними, и оставить комментарии к ним.

Это моя схема базы данных

(удалены некоторые столбцы, такие как: made_time, user_ip ...etc)

- documents:
----------------------
-- document_id
-- document_title
-- document_content
-- document_category

- comments:
----------------------
-- comment_id
-- comment_content
-- document_id
-- user_id

- users:
----------------------
-- user_id
-- user_name
-- user_type
-- user_password

- permissions:
----------------------
-- document_id
-- user_id

После того, как пользователь войдет в систему, PHP просмотрит все документы, к которым он может получить доступ с помощью этого SQL-запроса:

SELECT d.document_title
FROM documents AS d, permission AS p
WHERE d.document_id = p.document_id AND p.user_id = '12'

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

Теперь представьте количество строк, созданных для одного документа, которым совместно пользуются 200 пользователей по сети, это будет 201 строка в таблице разрешений !!который я считаю плохим подходом

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

- permissions:
----------------------
-- document_id
-- users_ids

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

Пожалуйста, посоветуйте мне и оставьте свой отзыв

Спасибо

Answer 1

Представьте себе случай, когда вместо записи на разрешение, имеющей столько записей, сколько разрешений, вы бы имели такие значения, как:

id1, id2, ..., idn

Сейчасдавайте рассмотрим несколько проблем:

Количество привилегий

При изменении, которое вы намереваетесь выполнить, вам нужно будет подсчитать количество запятых (и добавить 1) для каждого разрешения, что будетвызвать у вас много головной боли.В настоящее время вы можете просто посчитать количество записей и сгруппировать результаты по своему усмотрению.

Добавление нового разрешения в документ

Предположим, вам нужно добавить идентификатор в список разрешенийдокумент.В этом случае вам придется искать запись разрешения документа.Если он не найден, вам нужно будет вставить запись и убедиться, что там указан ваш идентификатор.Если найден, то вам придется обновить ту же запись.В настоящее время это просто вставка, если разрешение не существует, часто у вас уже есть информация и вам даже не нужно запрашивать.

Удаление разрешения из документа

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

Поиск документов, на которые у пользователя есть права доступа

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

* 1022.*

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

1NF

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

Answer 2

Во-первых, ваш запрос должен быть:

SELECT d.document_title
FROM documents d JOIN
     permission p
     ON d.document_id = p.document_id 
WHERE p.user_id = 12;

Использовать правильный JOIN синтаксис.И предположительно user_id - это число, поэтому сравнение должно проводиться с числом, а не строкой.

Во-вторых, когда вы описываете документы, у них, кажется, есть владельцы.Итак, documents должно иметь что-то вроде owner_user_id.Или, возможно, право собственности - это тип разрешения.

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

В-четвертых, наличие 200 строк для 200 пользователей не является проблемой a priori .Вы, конечно, не хотите исправлять это путем хранения данных, противоречащих методам реляционных баз данных, то есть объединяя целые числа в строки для хранения нескольких значений в одном столбце.

Вместо этого вы можете рассмотреть возможность введения некоторыхконцепция «групп», чтобы пользователи могли присоединиться к группе, и группа имеет доступ к документам.