Посібник для початківців щодо розробки баз даних SQL [закрито]


127

Чи знаєте ви гарне джерело, щоб навчитися проектувати рішення SQL?

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

  1. Які таблиці будувати та як їх пов’язувати
  2. Як створити різні масштаби (невеликий додаток клієнта до величезного розповсюдженого веб-сайту)
  3. Як писати ефективні / ефективні / елегантні SQL запити

Відповіді:


60

Я почав із цієї книги: Чітко пояснений дизайн реляційних баз даних (серія Morgan Kaufmann в системах управління даними) (м. М'яка обкладинка) Яна Л. Харрінгтона і вважав це дуже зрозумілим і корисним

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

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


1
Початок проектування бази даних: від початківця до професіонала - Клер Черчер?
Энтузиазм

40

Я почав з цієї статті

http://en.tekstenuitleg.net/articles/software/database-design-tutorial/intro.html

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


Любіть цей посібник, спасибі
MsO

Посилання у цій відповіді більше не працює.
Програмне забезпечення Grizzly Peak

1
Здається, посилання знову працює.
користувач8576017

1
Посилання більше не працює
jat255


28

Досвід має велике значення, але з точки зору дизайну столу ви можете багато чого навчитися з того, як працюють такі ORM, як "Зимова сплячка" та "Грааль", щоб зрозуміти, чому вони роблять щось. В додаток:

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

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

  3. Мені також подобається створити та змінити стовпчик часових позначок.

  4. Переконайтесь, що кожен стовпець, який ви робите, "у якому стовпець = val" у будь-якому запиті, має індекс. Можливо, не найдосконаліший у світі індекс для типу даних, але принаймні індекс.

  5. Налаштуйте свої закордонні ключі. Також встановіть правила ON DELETE та ON MODIFY, якщо це доречно, або для каскаду, або для встановлення нуля, залежно від вашої структури об'єкта (тому вам потрібно видалити лише один раз у "голівці" вашого об'єктного дерева, і всі суб'єкти цього об'єкта отримують видаляється автоматично).

  6. Якщо ви хочете модулювати свій код, ви можете модулювати схему БД - наприклад, це область "замовники", це область "замовлення", і це "товари", і використовувати таблиці приєднання / посилання між ними, навіть якщо вони у відносинах 1: n, і, можливо, дублювати важливу інформацію (тобто дублювати назву продукту, код, ціну в таблиці замовлення_деталей). Прочитайте про нормалізацію.

  7. Хтось інший порекомендує прямо протилежне для деяких або всього вищезазначеного: p - ніколи не єдиний справжній спосіб зробити якісь речі, е!


1
ОРМ, всі ваші пункти є антибаз .
PerformanceDBA

1
Додавання індексів не завжди означає більшу швидкість. Іноді вони справді роблять запити повільніше. Це дійсно залежить від запиту, і ви повинні перевірити їх, explain analyzeякщо індекс є корисним.
ArashM



2

Це питання, які, на мою думку, потребують різних знань з різних областей.

  1. Ви просто не можете заздалегідь знати, які "таблиці" будувати, ви повинні знати проблему, яку потрібно вирішити, і відповідно розробити схему;
  2. Це поєднання рішення дизайну баз даних та спеціальних можливостей постачальника вашої бази даних (тобто, ви повинні перевірити документацію своїх (r) dbms і врешті-решт вивчити деякі "поради та рекомендації" щодо масштабування); також конфігурація ваших dbms має вирішальне значення для масштабування (реплікація, розподіл даних тощо);
  3. знову ж таки, майже кожен rdbms поставляється з певним "діалектом" мови SQL, тому, якщо ви хочете ефективні запити, ви повинні вивчити саме цей діалект --btw. Напевно, написати елегантний запит, який також є ефективним - це велика справа: елегантність та ефективність часто суперечать цілям--

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


2

Минуло чимало часу, коли я прочитав його (тож я не впевнений, наскільки це все ще актуально), але мій спогад полягає в тому, що книга SQL for Smarties Джо Селко надає багато інформації про написання елегантних, ефективних та ефективних запитів .


четверте видання 2010 року може бути
оновленим

1
Книга Челко - це дослідження помилок і розширює поняття реалізації в коді того, що слід реалізувати в базі даних.
PerformanceDBA
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.