Десять характерних помилок у проектуванні бази даних

Зауваження:


Я вже двічі піднімав цю тему. Якщо Ви хочете послухати подкаст-версію, відвідайте блискучий сайт Грега Лоу SQL Down Under. Я також представив урізану десятихвилинну версію у PASS для Simple-Talk. Спочатку їх було десять, потім шість, а зараз знову десять. Але ці десять не ті ж самі десять помилок, які були спочатку, вони відображають моє сьогоднішнє розуміння.


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


Отже, список:



  1. Поганий проект / планування
  2. Ігнорування нормалізації
  3. Слабкі стандарти іменування
  4. Відсутність документації
  5. Одна таблиця для зберігання всіх значень домену
  6. Використання стовпців identity / guid в якості єдиного ключа
  7. Не використання коштів SQL для підтримки цілісності даних
  8. Не використання збережених процедур для забезпечення доступу до даних
  9. Спроба генерувати об'єкти
  10. Недостатнє тестування

Поганий проект / планування


"Якщо Ви не знаєте, куди йдете, то будь-яка дорога приведе вас туди" – Джордж Харрісон


Пророчі слова для всіх областей життя і опис проблеми, якої зачумлений багато сучасні проекти.


Дозвольте мені запитати: Ви найняли б підрядника для будівництва будинку, щоб вимагати від нього заливати фундамент на наступний же день? Або що гірше, Ви вимагали б, щоб це було зроблено без плану або проекту будинку? Хочеться сподіватися, що Ви відповіли "Ні" на обидва питання. Проект необхідний як гарантія, що будинок, який Ви хочете, буде побудований, і що земля, на якій Ви будуєте його, не провалиться в яку-небудь підземну печеру. Якщо Ви відповіли "Так", я не впевнений, чи допоможе Вам те, що я збираюся розповісти.


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


Оскільки база даних – наріжний камінь майже кожного бізнес проекту, то якщо ви не знайдете час, щоб визначити вимоги до проекту і те, як база даних буде їм задовольняти, тоді, ймовірно, весь проект піде не так і стане некерованим. Крім того, якщо Ви не зробите правильний проект бази даних на самому початку, то тоді Ви зіткнетеся з тим, що будь-які істотні зміни в структурі бази даних, які потрібно зробити, будуть чинити величезний вплив на весь проект, що значно збільшить ймовірність збільшення термінів його виконання.


Занадто часто належна фаза планування ігнорується на користь "отримання зробленого". Якщо щодо якого-небудь напряму проект зустрічає перешкоду, і неминуче виникають проблеми через брак належного проектування і планування, то ні "ніякого часу", щоб повернутися, щоб виправити ситуацію належним чином, використовуючи належні методи. Оскільки коли починається "рубка", благі обіцянки повернутися і виправити дещо пізніше, виконуються, насправді, дуже рідко.


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


Ігнорування нормалізації


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


Концепція нормалізації протягом близько 30 років є підставою, на яку спирається SQL і реляційні бази даних. Іншими словами, SQL був створений для роботи з нормалізованими структурами даних. Нормалізація – Це не тільки якийсь змова програмістів баз даних проти прикладних програмістів (що є просто побічним ефектом!)


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


Ця адитивна природа надзвичайно важлива не тільки для простоти розробки, але також і для продуктивності. Індекси є найбільш ефективними, коли вони можуть працювати з усім ключове значення. Кожного разу, коли Вам потрібно використовувати SUBSTRING, CHARINDEX, LIKE і так далі, щоб витягнути значення, яку об'єднано з іншими значеннями в єдиному стовпці (наприклад, щоб виокремити прізвище людини з стовпця, який містить повне ім'я), парадигма SQL починає ламатися, і дані стають все менш доступними для пошуку.


Отже, нормалізація ваших даних істотна для гарної продуктивності і простоти розробки, але залишилося питання: "Який нормалізації достатньо?" Якщо Ви читали які-небудь книги з нормалізації, то Ви чули багато разів, що суттєвою є 3-я нормальна Форма, але дійсно корисні і 4-ті та п'яте Нормальні Форми і, як тільки Ви стикаєтеся з ними, не шкодуйте часу, необхідного на нормалізацію.


Проте насправді часто виявляється, що не завжди навіть перша Нормальна Форма створюється правильно.


Кожного разу, коли я бачу таблицю з повторюваними іменами стовпців, які відрізняються лише додаванням числа, я приходжу в жах. І я жахаюся досить часто. Розглянемо наступний приклад таблиці Customer (Клієнт):



Виглядає складніше, чи не так? Але це первісне враження. Відверто кажучи, мені буде потрібно більше часу, щоб описати детально таблиці прикладу. Проте з'явилися величезні переваги:



SELECT *
FROM Customer
     JOIN CustomerType
ON Customer.CustomerTypeId = CustomerType.CustomerTypeId
     JOIN CreditStatus
ON Customer.CreditStatusId = CreditStatus.CreditStatusId



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


По-друге, навіть якщо це стало затребуваною завданням, SQL має повний набір команд, які Ви можете використовувати, щоб додати стовпці в таблиці, а використання системних таблиць дає можливість досить просто побудувати скрипт для додавання одного і того ж стовпця в сотні таблиць відразу. Це буде не таким простим зміною, але й не настільки важким, щоб переважити великі вигоди.


Призначення даної ради полягає в тому, що краще робити роботу сумлінно, створюючи стабільні та легко підтримувані структури, замість того, щоб спробувати виконати найменший обсяг роботи для якнайшвидшого запуску проекту. Зведення таблиць до поданням однієї "речі" означає, що більшість змін торкнеться тільки одну таблицю, з чого випливає, що в майбутньому вас очікує менше переробок.


Використання стовпців identity / guid в якості єдиного ключа


Перша Нормальна Форма диктує, що всі рядки в таблиці повинні однозначно ідентифікуватися. Отже, кожна таблиця повинна мати первинний ключ. SQL Server дозволяє Вам визначити числовий стовпець як стовпець IDENTITY, Після чого автоматично генеруються унікальні значення для кожної додається рядка. Крім того, Ви можете використовувати NEWID() (Або NEWSEQUENTIALID()) Для генерації випадкового 16-байтового унікального значення для кожного рядка. Такі типи значень, коли вони використовується як ключі, називаються сурогатними ключами. Слово "сурогатний" означає "що-небудь для заміни ", і в даному випадку, сурогатний ключ повинен стати заміною природного ключа.


Проблема полягає в тому, що занадто багато проектувальників використовують стовпець сурогатного ключа в якості єдиного ключового стовпця на даній таблиці. Значення сурогатного ключа не представляють ніякого фактичного значення в реальному світі; вони призначені виключно для того, щоб однозначно ідентифікувати кожен рядок.


Давайте розглянемо таку таблицю Part, В якій PartID столбцом IDENTITY і первинним ключем таблиці:























PartID  PartNumber  Description 
———— ———— ————
1 XXXXXXXX Частина X
2 XXXXXXXX Частина X
3 YYYYYYYY Частина Y

Скільки рядів знаходиться в цій таблиці? Ну, здається, що три, проте чи не є рядки з PartID 1 і 2 фактично однієї і тієї ж рядком, тобто дублікатами? Або ж це дві різних рядки, які повинні бути унікальними, але були визначені неправильно?


Емпіричне правило, яке я використовую, звучить просто. Якщо людина не в змозі вибрати, який рядок таблиці йому потрібна без знання сурогатного ключа, то Ви повинні переглянути структуру вашого проекту. Ось чому має бути певний ключ у таблиці, щоб гарантувати унікальність, у нашому випадку це, ймовірно, PartNumber.


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


Не використання коштів SQL для підтримки цілісності даних


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


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


Правила, які є додатковими, з іншого боку, є вірними кандидатами на те, щоб перемістити їх у бізнес-шар програми. Розглянемо, наприклад, таке правило: "У першу половину місяця ніяка деталь не може бути продана з більше ніж 20%-ою знижкою без схвалення менеджера ".


У цілому, ці правило звучить не дуже чітко, не дуже добре контролюється, і піддається частим змінам. Наприклад, що станеться, коли на наступному тижні максимальна знижка складе 30%? Або коли визначення "першої половини місяця" зміниться на "від 15 днів до 20 днів"? Найбільш ймовірно, що Ви не захочете переносити труднощі реалізації цих складних часових бізнес-правил у код SQL Server; бізнес-шар – Краще місце, щоб реалізувати такі правила там.


Однак розгляньте правило більш уважно. Тут є елементи, які, ймовірно, ніколи не будуть змінюватися. Наприклад.



Ці аспекти бізнес-правила очевидно повинні приписуватися базою даних та схемою. Навіть якщо сутність правила застосовується в бізнес-шарі, Вам все ж потрібно мати таблицю в базі даних, в яку записується розмір знижки, дата, коли вона пропонувалася, ідентифікатор особи, який її схвалив і так далі. На стовпці Discount Ви повинні мати обмеження CHECK, Яке обмежить допустимі значення інтервалом між 0.00 і 0.90 (або будь-яким іншим максимумом). Мало того, що це застосує ваше правило "максимальної знижки", але також буде служити засобом захисту від користувача, що входить знижку 200% або негативну знижку помилково. На стовпці ManagerID Ви повинні помістити обмеження зовнішній ключа, який посилаються на таблицю менеджерів (Managers), і гарантує, що введений ідентифікатор відповідає особистості реального менеджера (або, як альтернативу, тригер, який вибирає тільки ті EmployeeIds, Які відповідають менеджерам).


Тепер, принаймні, ми можемо бути впевнені, що дані задовольняють всім основним правилам, яким вони повинні підкорятися, і, таким чином, нам ніколи не доведеться кодувати дещо подібне, щоб перевірити, що дані хороші:


SELECT CASE WHEN discount <0 then 0 else WHEN discount> 1 then 1 …


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


Не використання збережених процедур для забезпечення доступу до даних


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


Підтримка


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


Інкапсуляція


Збережені процедури дозволяють Вам так "інкапсулювати" будь-які структурні зміни, які потрібно зробити в базі даних, щоб вплив на призначені для користувача інтерфейси було мінімально. Наприклад, Ви спочатку моделювали один телефонний номер, але тепер потрібно необмежену кількість телефонних номерів. Ви могли б залишити єдиний телефонний номер у виклику процедури, але зберігати його в іншій таблиці як тимчасовий захід, або навіть постійно, якщо Ви маєте "первинний" номер деякого виду, який Ви завжди хочете показувати. Тепер могла б бути побудована збережена процедура для обробки інших телефонних номерів. При цьому дія на призначені для користувача інтерфейси могло б бути досить незначним, в той час як код збережених процедур може істотно змінитися.


Безпека


Збережені процедури можуть забезпечити специфічний і гранульований доступ до системи. Наприклад, Ви можете мати 10 збережених процедур, які певним чином оновлюють таблицю X. Якщо користувачеві необхідно оновити конкретний стовпець у таблиці, і Вам потрібно гарантувати, що він ніколи не поновить ніякі інші стовпці, то Ви можете просто надати цьому користувачеві дозвіл на виконання тільки цієї однієї процедури з десяти, яка і йому дозволить виконати необхідне оновлення.


Продуктивність


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


У 2005, є установка бази даних "вимушена параметризація" (PARAMETERIZATION FORCED), Яка при включенні змусить зберігати плани всіх запитів. Це не покриває більш складні ситуації, які доступні процедурам, але може надати велику допомогу. Є також можливість, відома як plan guides, яка дозволяє Вам відкинути план для відомого типу запитів. Обидві ці можливості повинні допомогти, коли збережені процедури не використовуються, хоча збережені процедури роблять цю роботу без всяких трюків.


Цей список можна продовжити. Є також і недоліки, оскільки немає нічого досконалого. Для кодування збережених процедур може знадобитися більше часу, ніж при використанні безпосередньо переданих запитів. Однак кількість часу, необхідного на проектування інтерфейсу і його реалізацію, варта того, коли все сказано і зроблено.


Спроба кодувати загальні об'єкти T-SQL


Я вже торкався цього предмета раніше при обговоренні загальних доменних таблиць, але дана проблема має більш загальний сенс. Кожен новий програміст T-SQL, коли вперше починає кодувати збережені процедури, думає: "дуже шкода, що я не можу передати назву таблиці як параметр у процедуру." Це дійсно здається вельми привабливим: одна спільна збережена процедура, яка може виконати свої операції на будь-якій таблиці, яку Ви оберете. Проте цього слід уникати, оскільки це може дуже негативно позначитися на продуктивності і фактично зробить життя більш важкою, в кінцевому рахунку.


Об'єкти T-SQL не роблять "загальне" легко, значною мірою тому, що основний акцент при проектуванні в SQL Server зроблений на полегшенні повторного використання плану, а не коду. SQL Server працює найкраще, коли Ви мінімізуєте невідомості, щоб він зміг зробити найкращий можливий план. Чим більше робиться для узагальнення плану, тим менше це дозволяє оптимізувати його.


Відзначте, що я спеціально не кажу про процедури динамічного SQL. Динамічний SQL – великий інструмент, коли Ви маєте процедури, які не можна іншими способами зробити оптимізуються / керованими. Хороший приклад – процедура пошуку з безліччю різних варіантів вибору. Попередньо відкомпільоване рішення з численними умовами OR, можливо, дасть найгірший план і неважливі результати, особливо якщо використання параметрів є спорадичним.


Однак головний пункт цієї ради полягає в тому, щоб уникати кодування дуже загальних об'єктів, таких, які беруть назва таблиці і двадцять пар ім'я / значення як параметр і дозволяють Вам оновлювати значення в таблиці. Наприклад, Ви могли б написати процедуру, яка починається так:


CREATE PROCEDURE updateAnyTable
@tableName sysname,
@columnName1 sysname,
@columnName1Value varchar(max)
@columnName2 sysname,
@columnName2Value varchar(max)


Ідея полягає в динамічній завданні імені стовпця і значення для передачі їх у оператор SQL. Це рішення нічим не краще, ніж просте безпосереднє виконання оператораUPDATE. Крім цього, будуючи збережені процедури, Ви повинні будувати їх орієнтованими на кожне завдання, виконувану для таблиці (або безлічі таблиць.) Це дає Вам кілька переваг:



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


У моїй книзі Apress, Pro SQL Server 2005 Database Design and Optimization, я пропоную кілька таких "шаблонів" (Головним чином, для тригерів, але і для збережених процедур теж), всі з яких мають вбудовану обробку помилок. Я пропоную Вам побудувати свою власну систему (можливо, засновану на моїй), щоб використовувати її, коли Вам необхідно вручну будувати тригери / процедури або що б то не було ще.


Недостатнє тестування


Коли приладова панель у вашому автомобілі каже, що двигун перегрітий, на що Ви грішіть в першу чергу? Двигун. А чому не припустити, що зламаний індикатор? Або щось ще менш важливе? Є дві причини:



Оскільки професіонали баз даних знають, перша річ, на яку варто грішити, коли бізнес-система працює повільно, – це база даних. Чому? По-перше, тому, що це центральна частина більшості будь-яких бізнес-систем, а по-друге, тому що це також дуже часто вірно.


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


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


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


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


Як правило, головні помилки знаходяться швидко, особливо пов'язані з продуктивністю. Якщо ви відразу спробували запустити систему при повному навантаженні з боку користувачів, фонових процесів, технологічних процесів, процедур обслуговування системи, ETL і т.д., то Ви, мабуть, виявите, що не очікували всіх цих проблем з блокуваннями, які викликаються користувачами, створюють дані, у той час як інші читають їх, або проблем з апаратними засобами, викликаними їх поганої налаштуванням. Можуть пройти тижні, перш ніж стихнуть крики "SQL Server не може обробити це" навіть після того, як Ви зробили належну настройку.


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


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


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


Резюме


Проект бази даних і його реалізація – наріжний камінь будь-яких проектів, орієнтованих на обробку даних (читайте 99.9% бізнес-додатків), і повинен розглядатися таким, коли Ви займаєтеся розробкою. Ця стаття, мабуть, кілька повчальна, служить більше нагадуванням мені і того, хто її читає. Деякі поради типу належного планування, використання нормалізації, строгого проходження стандартам іменування та документації вашої роботи – це речі, які навіть кращі адміністратори баз даних і архітектори даних змушені примушувати себе робити. У стані напруги, коли менеджер менеджера вашого менеджера лається на те, що процес затягується, не легко повернутися і нагадати їм, що вони платять Вам зараз, або вони платять Вам пізніше. Ці завдання приносять дивіденди, які дуже важко оцінити кількісно, оскільки, щоб оцінити кількість успіху, йому повинна передувати невдача. І навіть коли Ви процвітаєте в одній області, занадто часто незначні відмови несподівано виникають в інших частинах проекту, що взагалі робить непоміченими ваші успіхи.


Поради, які я даю тут, збиралися багато років; вони перевели мене з розряду посередніх програмістів / архітекторів бази даних у розряд хороших. Жоден з них не займе надмірного часу (окрім, можливо, проектування і планування), але всі вони зажадають більше часу, ніж проходження "легким шляхом". Давайте зійдемося на тому, що якщо б легкий шлях виявився дійсно легким у кінцевому рахунку, то я б відставив більш складний шлях в ту ж секунду. Але цього не можна сказати до тих пір, поки не буде отриманий кінцевий результат, і слід зрозуміти, що успіх залежить від початкової точки в тій же мірі, що і від фінальною.

Louis Davidson (Оригінал: Ten Common Database Design Mistakes)
Переклад: Моісеєнко С.І.
Оригінал перекладу

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*