Блог

У меня есть веб-приложение с несколькими объектами (таблицами).У каждого есть свои CRUD-страницы.

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

Я думал о двух сценариях.

1. Одна таблица для всех комментариев / файлов — таблица будет иметь некоторый идентификатор для объекта и конкретной записи.
2. Для каждого объекта отдельная таблица комментариев / файлов.

Файлы будут храниться на диске в каталоге.В таблице должно быть имя файла и некоторая дополнительная информация.

С точки зрения дизайна приложения, наличие одной уникальной таблицы для всех комментариев, кажется, имеет смысл. С точки зрения кода приложения это означает, что один и тот же SQL будет использоваться повторно для всех объектов. Это «классический способ», используемый большинством приложений, расширяющийся за счет использования одних и тех же активных записей и контроллеров, используемых для обработки комментариев и вложений для всех объектов.

С точки зрения SQL второе решение может быть полезным в некоторых базах данных, таких как MySQL, для получения большей выгоды от кэша памяти. Каждый комментарий / attachmlent, добавленный в 1-м решении, удалял бы из кэша памяти все запросы, влияющие на таблицу комментариев. В отдельных таблицах комментарий к одному объекту не приведет к аннулированию запросов к другим объектам. Но вам также потребуется больше файловых дескрипторов и больший кеш таблиц…. итак, чтобы выбрать это решение, вам потребуется решение, основанное на реальном, точном примере, где вы могли бы сравнить преимущества в скорости доступа к базе данных. И когда вы будете добавлять новые объекты, вы наверняка найдете ваше решение с таблицей комментариев для каждого объекта скучным, все можно было автоматизировать с помощью первого решения.

Это компромисс. С отдельной таблицей комментариев вы получаете простую, СУХУЮ (не повторяйтесь) схему, но вы не получаете ограничений внешнего ключа и, следовательно, каскадного удаления. Таким образом, если вы удаляете объект с комментариями, вы также должны помнить об удалении комментариев!

Если вы используете несколько таблиц комментариев, вы получаете ограничения FK и каскадное удаление, но у вас есть «мокрая» схема (вы повторяетесь). Например, каждая таблица комментариев может содержать столбец commentbody. Если вы измените это определение столбца, вам придется изменять его в каждой таблице комментариев!

Одно интересное решение для СУХОЙ схемы может включать наследование таблиц (см. http://www.postgresql.org/docs/9.0/interactive/ddl-inherit.html) но, пожалуйста, прочитайте раздел 5.8.1. Предостережения, поскольку есть некоторые «подводные камни» в отношении индексации, по крайней мере, в postgres.

В любом случае, спасибо вам за тщательное продумывание дизайна вашей базы данных!