Очень простой вопрос проектирования базы данных

Question

Допустим, у меня есть служба обмена сообщениями между пользователями, с открытыми и закрытыми сообщениями.Я бы хотел, чтобы «публичные» были видны всем, а «приватные» были ДЕЙСТВИТЕЛЬНО приватными.Какой из обоих проектов будет лучшим?

a)

Наличие единой базы данных с названием "messages" со столбцами

• id
• отправитель
• получатель
• отметка времени
• значение
• конфиденциальность (это будет логическое значение, 0 для частного и 1 для открытого)

или b)

Наличие двух баз данных, одна из которых называется "messages_public", а другая - "messages_private" с такими же следующими столбцами

• id
• отправитель
• получатель
• отметка времени
• значение

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

Answer 1

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

CREATE VIEW public_messages AS SELECT * FROM messages WHERE private = false;

, затем выберите ваши публичные сообщения в представлении public_messages.Это может помочь предотвратить неуклюжие ошибки программирования, когда private = false опущено в операторах выбора в коде.

Answer 2

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

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

Answer 3

Если они должны быть «ДЕЙСТВИТЕЛЬНО приватными», а не «своего рода приватными» или «приватными», то используйте подход единой таблицы, зашифруйте личные сообщения и расшифруйте их при выходе. Таким образом, если вы пушите, то худшее, что случается, - это проявление тарабарщины.

Но, в конце концов, я бы просто сказал: «Не совершайте ошибок».

Answer 4

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

• Если злоумышленник найдет способ сбросить всю общедоступную таблицу, то они, вероятно, также смогут получить messages_private для выгрузки.

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

Answer 5

Я думаю, что второе было бы адом для использования, и приложения выше этого были бы более склонны к ошибкам, чем с первым. Кстати, безопасность должна управляться на уровне приложения, то есть конфигурации сервера и самого пользовательского приложения. Удачи!

Answer 6

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