Является ли таблица "черной дыры" злой?

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

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

Каковы преимущества и недостатки этого метода?

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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

оригинальный вопрос, который вызвал ваш запрос, не стал основой MySQL "blackholes."

Что такое BLACKHOLE?

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

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

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

Какую технику вы просите?

Используемый вариант рассматривается как:

перенаправить INSERTed данные в другие таблицы
проверите журнал исходного действия INSERTion
отказаться от исходных данных INSERT

Таким образом, ответ на вопрос о "зле" или "за" / "против" совпадает с ответом на эти вопросы для вставленных/обновляемых VIEW (общий способ реализации № 1), триггерного аудита аудита (как большинство людей do # 2) и поведенческих переопределений/противодействий вообще (существует ряд способов достижения # 3).

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

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

Конечно, мои двоичные разряды!

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

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