У меня когда-то был стол, и он был блестящим и красивым. Он провел все финансовые операции для организации. И тогда мы начали загружать данные в него.
В текущем месяце они могут указывать и пересчитывать значения так часто, как они хотят. В последние 10 дней месяца они пересчитывали цифры -> запускали обработку ETL -> просматривали отчеты несколько раз в день. После окончания месяца книги запечатываются, и они не могут изменять значения.
Удивительно, сколько финансовых данных генерирует фирма, предоставляющая финансовые услуги ... Что-то, чего мы не поняли с нашим набором тестовых данных, это объем данных, который сделает их процедуры на конец месяца несостоятельными. Потребовалось все больше времени, чтобы удалить «данные текущего месяца», прежде чем заменить их новым пробным прогоном.
Нам нужно было что-то сделать, чтобы сделать его более быстрым для обработки, не нарушая некаталогизированный список «кто знает, что», все зависит от таблицы MonthlyAllocation. Я решил поиграть в мага и вытащить скатерть из-под них. Я пошел в старую школу и использовал разделенный вид . У данных уже был флаг IsComplete, поэтому я создал две таблицы - каждая с противоположными проверочными ограничениями: MonthlyAllocationComplete, MonthlyAllocationInComplete
Затем я создал разделенное представление с тем же именем, что и исходная таблица: MonthlyAllocation. Никакого процесса не было мудрее в отношении физического изменения, которое мы внесли в базу данных. Никаких отчетов не было, ни один из аналитиков с прямым доступом не сообщал ни о каких проблемах с этой «таблицей» до или после.
Классная история, братан, но куда ты идешь?
Что если у них там есть соглашение об именах, tbl_MonthlyAllocation? Что теперь? Тратим ли мы много человеко-часов на просмотр каждого ETL, каждого отчета, каждой специальной таблицы в организации и обновляем их для использования vw_MonthlyAllocation? И затем, конечно, все эти изменения проходят через Совет по изменениям, и это всегда быстрый и безболезненный процесс.
Вы, босс, можете спросить: какова награда компании за всю эту работу снова?
Другой вариант - мы оставляем это представление с именем tbl_ и не тратим все это время на тестирование, обновление и развертывание кода. Это становится забавным анекдотом, который вы объясняете всем новым сотрудникам, а также тем, у кого мало внимания, и которым приходится работать с базой данных о том, почему вы не согласны с именами объектов.
Или вы не можете дважды кодировать объекты с избыточными метаданными. База данных с радостью расскажет вам, что такое таблица, что такое представление, что такое табличная функция и т. Д.
Соглашения об именах - это хорошо, просто не загоняйте их в угол.
Class
?