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

Які важливі поняття, які розробники та інші фахівці з програмного забезпечення повинні знати про бази даних?

Правила відповідей:

Тримайте список недовго.
Одне поняття на відповідь найкраще.

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

Поясніть своє обґрунтування.
Чому ваша концепція важлива? Не кажіть просто "використовуйте індекси". Не впадайте в "кращі практики". Переконайте свою аудиторію дізнатися більше.

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

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

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

На жаль, відповідь на це - рухома мета. У період розквіту баз даних, починаючи з 1970-х на початку 1990-х, бази даних були для обміну даними. Якщо ви використовували базу даних, і ви не обмінювалися даними, ви або брали участь в академічному проекті, або витрачали ресурси, включаючи себе. Налаштування бази даних та приборкання СУБД були такими монументальними завданнями, що окупність, з точки зору даних, що експлуатувались неодноразово, мала бути величезною, щоб відповідати інвестиціям.

За останні 15 років бази даних стали використовуватись для зберігання стійких даних, пов’язаних лише з одним додатком. Побудова бази даних для MySQL або Access або SQL Server стала настільки звичайною, що бази даних стали майже звичайною частиною звичайного додатку. Іноді ця початкова обмежена місія підштовхується вгору повзанням місії, оскільки реальна цінність даних стає очевидною. На жаль, бази даних, які були розроблені з єдиною метою, часто різко виходять з ладу, коли їх починають відштовхувати від ролі, яка є загальноприйнятою та важливою для місії.

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

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

Концептуальне моделювання даних - це дійсно аналіз вимог з точки зору, орієнтованого на дані.

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

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

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

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

Вау!

Гарне питання. Нижче наведені деякі думки в не конкретному порядку:

1. Нормалізація, принаймні до другої нормальної форми, є важливою.

2. Цілісність посилань також є важливою з належними каскадними міркуваннями щодо видалення та оновлення.

3. Добре та правильне використання обмежень для перевірки. Нехай база може зробити якомога більше роботи.

4. Не розкидайте бізнес-логіку як в базі даних, так і в коді середнього рівня. Виберіть той чи інший, бажано, середній рівень коду.

5. Визначте послідовний підхід для первинних ключів та кластерних ключів.

6. Не переоцінюйте. Вибирайте свої індекси розумно.

7. Послідовне іменування таблиці та стовпців. Виберіть стандарт і дотримуйтесь його.

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

9. Не захоплюйтесь курок. Вони мають своє використання, але можуть ускладнювати речі в поспіху.

10. Будьте обережні з АДС. Вони чудові, але можуть спричинити проблеми з продуктивністю, коли ви не знаєте, як часто їх можуть викликати у запиті.

11. Отримайте книгу Celko про дизайн баз даних. Чоловік зарозумілий, але знає свої речі.

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

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

По-третє, розробникам потрібно зрозуміти базовий SQL, включаючи приєднання.

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

Вони повинні розуміти основні нормалізації, принаймні, перші три нормальні форми. Що б там не було, отримайте DBA. Для тих, хто має досвід роботи із залами судових засідань у США (і тут зараховуються випадкові телевізійні шоу), є мнемонічне "Залежить від ключа, всього ключа та нічого, крім ключа, тож допоможе тобі Кодд".

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

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

Вони повинні мати основні знання про те, як отримати план та як його читати загалом (принаймні, достатньо, щоб сказати, ефективні чи ні алгоритми).

Вони повинні нечітко знати, що таке тригер, що таке перегляд, і що можна розділити фрагменти баз даних. Їм не потрібні якісь деталі, але вони повинні знати, щоб запитати у DBA про ці речі.

Вони, звичайно, повинні знати, що не втручатися у виробничі дані, виробничий код або щось подібне, і вони повинні знати, що весь вихідний код переходить у VCS.

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

Основна індексація

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

• Що індексується у вашій базі даних, а що ні:
• Різниця між видами сканувань, способом їх вибору та способом написання запиту може впливати на цей вибір;
• Концепція висвітлення (чому ви не повинні просто писати SELECT *);
• Різниця між кластерним та некластеризованим індексом;
• Чому більше / більші індекси не обов'язково кращі;
• Чому слід намагатися уникати загортання стовпців фільтрів у функції.

Дизайнери також повинні знати про поширені антидіапазони індексів, наприклад:

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

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

Нормалізація

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

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

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

Як працюють індекси

Це, мабуть, не найважливіша, але напевно сама занижена тема.

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

Навіть більш досвідчені розробники можуть писати досить хороший (і складний) SQL, не знаючи більше про індекси, ніж " Індекс робить запит швидким ".

Це тому, що бази даних SQL роблять дуже гарну роботу, працюючи як чорний ящик:

Скажіть мені, що вам потрібно (gimme SQL), я подбаю про це.

І це ідеально підходить для отримання правильних результатів. Автору SQL не потрібно знати, що робить система за лаштунками, поки все не стане sooo slooooow .....

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

Тому я вважаю, що індексація - тема №1, яку не варто забувати під час роботи з базами даних . На жаль, забути це дуже просто.

Відмова від відповідальності

Аргументи запозичені з передмови моєї вільної електронної книги " Використовуйте індекс, Лука ". Я витрачаю досить багато часу на пояснення того, як працюють індекси та як правильно їх використовувати.

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

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

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

Уникання ін'єкцій SQL та забезпечення безпеки вашої бази даних

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

Існує чіткий Big-O в традиційному розумінні. Коли ви робите EXPLAIN PLAN(або еквівалент), ви бачите алгоритм. Деякі алгоритми включають вкладені петлі і є O ( n ^ 2). Інші алгоритми включають пошук B-дерева і є O ( n log n ).

Це дуже, дуже серйозно. Важливо зрозуміти, чому індекси мають значення. Це важливо для розуміння швидкості нормалізації швидкості та денормалізації. Важливо зрозуміти, чому в сховищі даних використовується зіркова схема, яка не нормалізується для оновлень транзакцій.

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

Крім того, наслідок: більше показників не краще.

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

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

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

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

Ще одна річ, яку розробники повинні розуміти, це те, що ви маєте пам’ятати про три бажання:

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

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

3. Безпека - ці дані є життєвою кров’ю вашої компанії, вони також часто містять особисту інформацію, яку можна викрасти. Дізнайтеся, як захистити свої дані від нападів ін'єкцій SQL та шахрайства та крадіжок особи.

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

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

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

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

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

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

Еволюційне проектування баз даних. http://martinfowler.com/articles/evodb.html

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

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

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

Принаймні знайте, що концепція та методології рефакторингу баз даних існують. http://www.agiledata.org/essays/databaseRefactoringCatalog.html

Класифікація та опис процесу дозволяють застосовувати також інструменти для цих рефактори.

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

- різні типи даних :

Використання правильного типу для правильної роботи зробить ваш дизайн БД більш надійним, ваші запити швидшими та полегшать ваше життя.

- Дізнайтеся про 1xM та MxM :

Це хліб і масло для реляційних баз даних. Вам потрібно зрозуміти відносини один-багато-багато-багато-багато і застосувати тоді, коли це доречно.

- Принцип " KISS " застосовується і до БД :

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

- Індекси :

Мало, якщо ви знаєте, що вони є. Вам потрібно зрозуміти, коли ними користуватися, а коли не потрібно.

також:

• Булева алгебра - твій друг
• Зображення: не зберігайте їх у БД. Не питайте, чому.
• Тест DELETE за допомогою SELECT

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

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

Про наступний коментар до відповіді Вальтера М.:

"Дуже добре написано! І історична перспектива чудово підходить для людей, які тоді не працювали з базами даних (тобто я)".

Історична перспектива в певному сенсі абсолютно вирішальна. "Ті, хто забуває історію, приречений повторити її". Cfr XML, що повторює ієрархічні помилки минулого, бази даних графіків, що повторюють мережеві помилки минулого, системи OO, що примушують ієрархічну модель до користувачів, тоді як усі, хто має навіть лише десяту частину мозку, повинні знати, що ієрархічна модель не підходить для загальних, цільове представлення реального світу, etcetera, etcetera.

Що стосується самого питання:

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

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

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

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

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

Проста повага.

• Це не просто сховище
• Ви, мабуть, не знаєте краще, ніж постачальник або DBA
• Ви не підтримаєте його о 3 ранку, коли старші менеджери кричать на вас

Розгляньте денормалізацію як можливого ангела, а не диявола, а також розглядайте бази даних NoSQL як альтернативу реляційним базам даних.

Крім того, я думаю, що модель Entity-Relation є обов'язковою інформацією для кожного розробника, навіть якщо ви не проектуєте бази даних. Це дозволить вам зрозуміти, про що йдеться у вашій базі даних.

Ніколи не вставляйте дані з неправильним кодуванням тексту.

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

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

Знайте, як ваш двигун буде конкретно виконувати запит, який ви пишете.

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

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

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

Знайте процес виконання двигуна бази даних та плануйте його.

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

Кожен вихователь C ++ написав клас коледжу в коледжі. Кожен графічний витівник написав у коледжі рейсер. Кожен веб-гек писав інтерактивні веб-сайти (як правило, до того, як у нас були "веб-рамки") в коледжі. Кожен апаратний ботанік (і навіть програмний ботанік) вбудував процесор у коледж. Кожен лікар розсікав цілий труп у коледжі, навіть якщо вона лише здасть мені артеріальний тиск і скаже мені, що мій холестерин сьогодні занадто високий. Чому бази даних будуть різними?

На жаль, сьогодні вони чомусь здаються різними. Люди хочуть, щоб .NET-програмісти знали, як працюють струни в C , але внутрішня частина ваших RDBMS не повинна надто турбувати вас .

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

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

Порядок стовпців у не унікальному покажчику важливий.

Перший стовпець повинен бути стовпцем, який має найбільшу мінливість за своїм змістом (тобто кардинальність).

Це сприяє можливості SQL Server створювати корисні статистичні дані щодо використання індексу під час виконання.

Розумійте інструменти, які використовуєте для програмування бази даних !!!

Я витратив стільки часу, намагаючись зрозуміти, чому мій код таємниче вийшов з ладу.

Наприклад, якщо ви використовуєте .NET, вам потрібно знати, як правильно використовувати об'єкти в System.Data.SqlClientпросторі імен. Вам потрібно знати, як керувати своїми SqlConnectionоб'єктами, щоб переконатися, що вони відкриті, закриті та, коли це необхідно, належним чином розміщені.

Вам потрібно знати, що коли ви використовуєте a SqlDataReader, його потрібно закрити окремо від вашого SqlConnection. Вам потрібно зрозуміти, як тримати з'єднання відкритими, коли це доцільно, як мінімізувати кількість звернень до бази даних (тому що вони відносно дорогі з точки зору часу на обчислення).

• Основні навички SQL
• Індексація.
• Справа з різними втіленнями DATE / TIME / TIMESTAMP.
• Документація драйверів JDBC для платформи, яку ви використовуєте.
• Робота з бінарними типами даних ( CLOB , BLOB тощо)

Для деяких проектів краще орієнтована об'єктно-орієнтована модель.

Для інших проектів реляційна модель краще.

Проблема невідповідності імпедансу і знати загальні недоліки або ORM.

Сумісність RDBMS

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

• уникайте розширень SQL RDBMS
• усунути тригери та зберігати процедури
• дотримуйтесь суворих стандартів SQL
• конвертувати типи даних поля
• зміни рівня ізоляції транзакцій

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

Не залежить від порядку рядків, повернутих за допомогою SQL-запиту.

http://www.reddit.com/r/programming/comments/azdd7/programmers_sit_your_butt_down_i_need_to_have_a/