Як я можу переконливо стверджувати проти дублювання стовпців бази даних?

Я почав працювати в новій організації, і одна з моделей, яку я бачив у базі даних, - це дублювання полів для полегшення запитів для запису для бізнес-аналітиків. Ми використовуємо Django та його ORM.

В одному випадку ми зберігаємо об’єкт MedicalRecordNumber з унікальною рядком, що ідентифікує пацієнта в певному контексті. У нас є об’єкти реєстрації, які відстежують пацієнтів та пов’язані з ними MedicalRecordNumbers , але замість того, щоб використовувати зв'язок із зовнішнім ключем, вони дублюють рядок, щоб вони могли уникнути написання приєднання ( не з причин продуктивності). Ця закономірність є загальною для всієї бази даних.

Для мене важливість чистоти моделі даних якраз для того, щоб я міг добре подумати над цим. Зайві складності - це витрата мого обмеженого часу на пізнавальну обробку. Це систематична проблема. Незручне написання приєднується до проблеми, що піддається виправленню. Я не обов'язково хочу виступати за повернення та зміну схеми, але мені б хотілося переконливо сформулювати проблеми з таким типом дублювання.

Ваша операційна база даних повинна бути сильно нормалізована, щоб зменшити аномалії .

Ваша аналітична база даних (склад) повинна бути сильно денормалізованою, щоб полегшити аналіз.

Якщо у вас немає окремої аналітичної бази даних, вам слід зробити кілька денормалізованих [матеріалізованих] поглядів.

Якщо ви скажете своїм старшим бізнес-аналітикам / менеджерам робити багато приєднань для простого аналізу, то вас можуть звільнити.

Agile Design Warehouse Design - це хороша книга

Дивіться мої швидкі н брудних сховищ даних рад тут

Я розумію, чому хтось хоче уникати написання приєднання для кожного вибору.

Але ви можете створити один раз представлення з об'єднанням і використовувати його замість ненормалізованої таблиці.

Так ви поєднуєте перевагу нормалізації з зручністю простого вибору.

Відповіді, які вже були використані, охоплюють "як уникнути дублювання" (використовуючи перегляди), але не чому. Вони в основному показують, що дублювання стовпців - це неправильне рішення проблеми, що спрощує написання запитів. Але питання "чому б не дублювати жоден випадковий стовпець лише для чортви його?" досі стоїть.

Відповідь "Через закон Мерфі". Закон Мерфі говорить, що:

Якщо щось може піти не так, воно буде.

У цьому випадку вміст кожного поля рядка дублюється стовпця повинен бути ідентичним вмісту кожного відповідного поля рядка вихідного стовпця. Що може піти не так, це те, що вміст деяких полів рядків може відрізнятися від оригіналів, спричиняючи хаос. Вам може здатися, що ви вжили всіх можливих запобіжних заходів, щоб переконатися, що вони не будуть відрізнятися, але закон Мерфі говорить, що оскільки вони можуть відрізнятися, вони будуть відрізнятися. І настане хаос .

Як приклад того, як це може статися, просто розгляньте той факт, що дублюються стовпці не заповнюються магією; хтось повинен насправді записати код, який зберігає в них значення, коли рядки створюються в оригінальній таблиці, а хтось повинен записати код, який постійно оновлює їх, коли оригінали змінюються. Якщо відмовитись від того, що це додає надмірного навантаження на код, який вносить дані в базу даних (а це, за визначенням, набагато важливіше, ніж будь-який код, який просто запитує базу даних), хтось десь за певних обставин може забути здійснити це дублювання. Тоді значення будуть відрізнятися. Або вони можуть пам’ятати, що проводити дублювання, але не в рамках транзакції, тому за певних рідкісних умов помилок це може бути опущено. Але мені не потрібно було витрачати час на написання цих прикладів,якщо це може піти не так, це буде.

Думати про це з точки зору компромісів, а не добре / погано, буде більш продуктивним. Вони продають переваги нормалізації (особливо консистенції) за переваги в застосуванні запитів.

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

Що ви можете зробити, щоб зменшити ризики та витрати?

• Створіть інструмент перевірки консистенції та запускайте його регулярно.
• Доступ до запису маршрутів через програмне забезпечення, яке постійно оновлює реплікувані дані.
• Додайте представлення даних або будуйте інструменти для запитів, які з'єднуються автоматично, щоб ділові люди могли продумати інформацію, а не внутрішню базу даних.

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

Трохи складніший метод запитів, ймовірно, буде кращим перед потенційною корупцією даних.

Щоб додати те, що запропонували інші хлопці вище. Це питання управління даними. Вам потрібно співпрацювати з відповідними зацікавленими сторонами: архітекторами даних та управителями даних, щоб розробити принципи даних, політику та конвенції про іменування.

Будьте терплячі та працюйте методично. Зміни не відбудуться протягом ночі.

Вийдіть.

Чесно кажучи, ви можете витратити місяці, сперечаючись про нормалізацію, послідовність та боротьбу з шаленими помилками, спричиненими суцільною лінню, а потім киньте.

Або ви можете просто заощадити час, розчарування та кинути зараз.

Хороші програмісти - дуже ліниві люди. Вони розуміють потреби клієнтів та менеджменту. Але найголовніше, що вони розуміють, що добре вирішувати проблеми, використовуючи добре розроблені та добре реалізовані рішення, економить їх особисто ВЕЛИЧЕЗНИЙ обсяг роботи, зусиль, а головне - агонії та стресу.

Тож вам було б набагато краще працювати в місці, яке добре розуміє та цінує хорошу техніку.

Щасти.

Поміркування: Можливо, потрібні інструменти BI / OLAP ... http://en.wikipedia.org/wiki/Online_analytical_processing