Триггеры базы данных / ссылочная целостность и кэширование в памяти - PullRequest
Новая
       22

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

5 голосов
/ 16 марта 2010

Видите ли вы, что триггеры базы данных / правила ссылочной целостности используются таким образом, что изменяют фактические данные в базе данных (изменение строки w в таблице x приводит к изменению строки y в таблице z)?

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

Есть ли у кого-нибудь реальный опыт с такой установкой / реальный опыт с рассмотрением такой установки и отказом от нее (каким путем вы пошли? Если кэшируете, как вы обеспечиваете целостность?)

1 Ответ

5 голосов
/ 16 марта 2010

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

  • Ссылочная целостность должна иметь
  • Кэширование квалифицированный должен иметь
  • Триггеры приятно иметь

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

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

Кэширование также часто считают «трудным» для правильного выполнения, хотя я не уверен, почему.

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

   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. Вы добавляете свой тег, и он вполне может быть сохранен в базе данных мгновенно - но обновляется ли тогда кэш?

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

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

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

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

...