Является ли стол «черной дыры» злом?

Question

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

Мне интересно, может ли это вызвать проблемы, как только разработчики, работающие над проектом, узнают об этом.

Каковы плюсы и минусы этой технологии ?

Редактировать : Мигание, о котором я подумал, когда увидел пример, касается транзакций: если по какой-то причине транзакция не удалась, вы найдете строку blackhole с исходными данными для исторических целей и, возможно, для помощи с отладкой - но это кажется, единственный +1, который я могу видеть с черными дырами. Идеи?

Answer 1

Я не думаю, что у черной дыры есть настоящие плюсы.

Написание кода триггера для перемещения данных, вероятно, не намного сложнее, чем написание кода для вставки данных в нужное место.

Как пишет Кристиан Одард, это не уменьшает сложность - просто перемещает его в место, где его действительно сложно отладить.

С другой стороны:

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

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

Поскольку триггеры являются побочными эффектами, и относительно легко вызвать огромный каскад триггеров, если вы не будете осторожны, я всегда пытался проектировать свои базы данных без использования триггеров; там, где триггеры - верный путь, я позволяю создавать их только моим опытным разработчикам. Трюк с черной дырой превращает триггеры в обычный, обычный способ работы. Это личная точка зрения, конечно.

Answer 2

Исходный вопрос , который вызвал ваш вопрос, не входит в суть "черных дыр" MySQL.

Что такое ЧЕРНАЯ ДЫРА?

В MySQL-говорящем, BLACKHOLE - это механизм хранения , который просто отбрасывает все введенные в него данные, аналогично нулевому устройству.Существует несколько причин для использования этого бэкэнда, но они, как правило, немного заумны:

• «Релейный» ведомый бинлог-фильтрСм. документы и здесь и здесь .
• БенчмаркингНапример, измерение накладных расходов двоичного журналирования, не беспокоясь о накладных расходах механизма хранения
• Различные вычислительные приемыСм. здесь .

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

Что такоетехника, о которой вы спрашиваете?

Рассматриваемое использование , по-видимому:

1. перенаправляет вставленные данные в другие таблицы
2. журнал аудитаисходное действие INSERTion
3. отбрасывает исходные данные INSERT

Таким образом, ответ на вопрос «зла» или «за» / «против» такой же, как и ответ на эти вопросы для вставки /обновляемые ВИДЫ (общий способ реализации # 1), ведение журнала аудита на основе триггеров (как большинство людей делают # 2) и поведенческие переопределения / противодействия в целом (есть ряд способов выполнить # 3).

Итак, каков ответ?

Ответ, конечно, «иногда эти методы уместны, а иногда нет».:) Ты знаешь, почему ты это делаешь?Является ли приложение лучшим местом для этой функциональности?Является ли абстракция слишком хрупкой, слишком негерметичной, слишком жесткой и т. Д.?

Answer 3

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

Answer 4

Как ни странно, сегодня я узнал и о существовании черных дыр.

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

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

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

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

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

Конечно, стоит всего два бита!

Answer 5

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

Также это снизит производительность вставки вдвое, поскольку для вставок требуется две вставки вместо одной.

И это денормализация, поскольку теперь вместо одной копии данных две.

Answer 6

Не делай этого. Тот факт, что это называется трюком, а не стандартным способом что-то делать, говорит мне достаточно.

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

Это интересный салонный трюк, ничего более.

Answer 7

Пожалуйста, не делай этого. Это не уменьшает сложность, оно просто перемещает его. Такая логика относится к прикладному уровню, где вы можете использовать более приятный язык, такой как PHP, Python или Ruby, для его реализации.

Answer 8

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