База данных инициировала / ссылочная целостность и кэширование в оперативной памяти

Простой ответ:

• Реляционная целостность - это обязательно
• Кэширование - это квалифицированное обязательно
• Триггеры - это приятно иметь

Более длинный ответ

Я разрабатываю приложения на реляционных базах данных с 1993 года (Dec RDB, раз уж вы спросили, а до этого на плоских файловых системах), и триггеры никогда не были популярны среди многих разработчиков, потому что они могут "удалить то, что вы не хотите удалять". Ссылочная целостность также часто не одобряется разработчиками, потому что базу данных в третьей нормальной форме с надлежащей ссылочной целостностью трудно собрать за несколько минут.

Кэширование также часто считается довольно "трудным" для правильной работы, хотя я не уверен, почему.

В то время как многие системы могут жить без триггеров, я бы сказал, что ни одна прикладная база данных не может спокойно жить без ссылочной целостности. Посмотрите на теги этого вопроса, база данных этого сайта будет иметь таблицу для тегов (вероятно, под названием 'Tag') и вопросов (вероятно, под названием 'Question'). Вопрос" будет иметь внешний ключ к первичному ключу таблицы Tag, но поскольку у вопросов может быть много тегов, а у тегов - много вопросов, я бы предположил, что отношения будут выглядеть следующим образом:

   Question
   (TagId)         1 | Database triggers / referential integrity and in-memory caching
      |  
    -----
    | | |
  QuestionTag
 (QuestionId)       1 | 1  ... 1 | 2  ... 1 | 3 ...
    (TagId)
    | | |
    -----
      |
     Tag            1 | database ... 2 | referential-integrity ... 3 | triggers ...
   (TagId)

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

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

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

Триггеры могут обеспечивать ссылочную целостность, скажем, тег, который вы добавляете - "мусор", но к тому времени, как администраторы увидят его, три вопроса будут помечены "мусором". Затем администраторы решают удалить тег 'rubbish' - но что делать с вопросами, помеченными этим тегом? Если в таблице 'tag' есть триггер, который срабатывает при удалении, то он может пробежаться по таблице 'question' и удалить все ссылки на 'rubbish'. Существует множество альтернатив этому подходу - многие из которых являются программными обходными путями - но есть ли более чистая альтернатива?

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

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