mirror of
https://github.com/treffynnon/sqlstyle.guide.git
synced 2025-03-09 12:49:51 -05:00
fix: remove trailing whitespace
This commit is contained in:
Simon Holywell
parent
89cd5bee80
commit
e61d43db43
8 changed files with 112 additions and 112 deletions
|
|
@ -9,7 +9,7 @@ Style][celko] de Joe Celko afin de faciliter leur adoption par les équipes qui
|
|||
|
||||
Il est aisé d'inclure ce guide au [format Markdown][dl-md] dans la base de code d'un projet, ou de l'y référencer pour que tout·e membre du projet puisse le lire librement, ce qui est bien plus dur à faire avec un livre physique.
|
||||
|
||||
Ce guide de style SQL par [Simon Holywell][simon] est proposé sous licence [Creative Commons
|
||||
Ce guide de style SQL par [Simon Holywell][simon] est proposé sous licence [Creative Commons
|
||||
Attribution-Partage dans les Mêmes Conditions 4.0 International][licence].
|
||||
Fondé sur un travail disponible sur [https://www.sqlstyle.guide/][sqlstyleguide].
|
||||
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
|
||||
***
|
||||
|
||||
**日本語訳について**
|
||||
**日本語訳について**
|
||||
|
||||
日本語訳は誤訳や[原文の最新版][sqlstyleguide]に追随していない恐れがあります。誤訳や改善点があれば、GitHubの[issue][issue]または[pull request][pull]を使用するか、[Twitter][twitter-ja]でお知らせください。
|
||||
日本語訳は誤訳や[原文の最新版][sqlstyleguide]に追随していない恐れがあります。誤訳や改善点があれば、GitHubの[issue][issue]または[pull request][pull]を使用するか、[Twitter][twitter-ja]でお知らせください。
|
||||
翻訳: 久利史之 [@nkuritw][twitter-ja]
|
||||
|
||||
[twitter-ja]: https://twitter.com/nkuritw
|
||||
|
|
@ -13,11 +13,11 @@
|
|||
|
||||
## 概要
|
||||
|
||||
このガイドラインは利用の他、[fork][fork]したり、自分自身のものに改変したりすることができます。ここで大事なのはスタイルを選択しそれを踏襲することです。変更の提案やバグの修正にはGitHubの[issue][]または[pull request][pull]を使用してください。
|
||||
このガイドラインは利用の他、[fork][fork]したり、自分自身のものに改変したりすることができます。ここで大事なのはスタイルを選択しそれを踏襲することです。変更の提案やバグの修正にはGitHubの[issue][]または[pull request][pull]を使用してください。
|
||||
|
||||
このガイドラインは『[Joe Celko's SQL Programming Style][celko]』と互換性があり、すでにその本を読んだことがあるチームにとっては適用が容易です。このガイドはより独断的な部分もあればより緩やかな部分もあります。Celkoの書籍は各ルールの背後にあるエピソードや根拠を詳細に掲載していますが、このガイドはより簡潔になっています。
|
||||
このガイドラインは『[Joe Celko's SQL Programming Style][celko]』と互換性があり、すでにその本を読んだことがあるチームにとっては適用が容易です。このガイドはより独断的な部分もあればより緩やかな部分もあります。Celkoの書籍は各ルールの背後にあるエピソードや根拠を詳細に掲載していますが、このガイドはより簡潔になっています。
|
||||
|
||||
このガイドの[Markdown版][dl-md]を活用すれば、紙の本では難しいプロジェクトのコード規約に含めたり、プロジェクトの参加者がその場で参照し自由に読んだりすることが容易になります。
|
||||
このガイドの[Markdown版][dl-md]を活用すれば、紙の本では難しいプロジェクトのコード規約に含めたり、プロジェクトの参加者がその場で参照し自由に読んだりすることが容易になります。
|
||||
|
||||
SQLスタイルガイド by [Simon Holywell][simon] は、[クリエイティブ・コモンズ 表示-継承4.0国際ライセンス][licence-ja]の下にあります。原本は[https://www.sqlstyle.guide][sqlstyleguide]です。
|
||||
|
||||
|
|
@ -1200,7 +1200,7 @@ ZONE
|
|||
[rivers]: https://practicaltypography.com/one-space-between-sentences.html
|
||||
"Practical Typography: one space between sentences"
|
||||
[reserved-keywords]: #reserved-keyword-reference
|
||||
"Reserved keyword reference"
|
||||
"Reserved keyword reference"
|
||||
[eav]: https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model
|
||||
"Wikipedia: Entity-attribute-value model"
|
||||
[sqlstyleguide]: https://www.sqlstyle.guide
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ It is easy to include this guide in [Markdown format][dl-md] as a part of a
|
|||
project's code base or reference it here for anyone on the project to freely
|
||||
read—much harder with a physical book.
|
||||
|
||||
SQL style guide by [Simon Holywell][simon] is licensed under a [Creative Commons
|
||||
SQL style guide by [Simon Holywell][simon] is licensed under a [Creative Commons
|
||||
Attribution-ShareAlike 4.0 International License][licence].
|
||||
Based on a work at [https://www.sqlstyle.guide/][sqlstyleguide].
|
||||
|
||||
|
|
|
|||
|
|
@ -7,17 +7,17 @@ własne – najważniejsze jest abyś wybrał styl i się go trzymał. Jeśli ch
|
|||
zasugerować zmiany lub poprawić błędy, utwórz na GitHubie [zgłoszenie][issue]
|
||||
lub zrób [pull request][pull].
|
||||
|
||||
Wytyczne zostały zaprojektowane tak, aby były zgodne z podręcznikiem
|
||||
Wytyczne zostały zaprojektowane tak, aby były zgodne z podręcznikiem
|
||||
[SQL Programming Style][celko] Joego Celko i były łatwe do przyswojenia
|
||||
dla zespołów, które już przeczytały tę książkę. Poniższy przewodnik w niektórych
|
||||
obszarach jest nieco bardziej stanowczy, a w innych nieco swobodniejszy.
|
||||
obszarach jest nieco bardziej stanowczy, a w innych nieco swobodniejszy.
|
||||
Z pewnością jest bardziej zwięzły, podczas gdy [książka Celko][celko] każdą regułę okrasza
|
||||
anegdotami i uzasadnieniem w formie przemyślanej wypowiedzi.
|
||||
|
||||
Poniższy podręcznik można łatwo umieścić w głównym repozytorium projektu poprzez pobranie go
|
||||
Poniższy podręcznik można łatwo umieścić w głównym repozytorium projektu poprzez pobranie go
|
||||
w [formacie Markdown][dl-md] lub podając link bezpośrednio do tej strony.
|
||||
Dzieki temu każda osoba biorąca udział w projekcie będzie mogła swobodnie przeczytać
|
||||
umieszczone tutaj wytyczne – o wiele trudniej jest to osiągnąć przy pomocy fizycznej
|
||||
Dzieki temu każda osoba biorąca udział w projekcie będzie mogła swobodnie przeczytać
|
||||
umieszczone tutaj wytyczne – o wiele trudniej jest to osiągnąć przy pomocy fizycznej
|
||||
papierowej książki.
|
||||
|
||||
Podręcznik stylu SQL [Simona Holywella][simon] jest wydany na licencji
|
||||
|
|
@ -31,11 +31,11 @@ Międzynarodowe][licence]. Na podstawie pracy dostępnej pod adresem
|
|||
|
||||
* Używaj spójnych oraz opisowych identyfikatorów i nazw.
|
||||
* Rozsądnie wykorzystuj białe znaki i wcięcia, tak aby ułatwić czytanie kodu.
|
||||
* Ze względu na przenośność kodu staraj się używać wyłącznie standardowych funkcji SQL
|
||||
* Przechowuj informacje o czasie i dacie w formacie zgodnym z [ISO 8601][iso-8601]
|
||||
(`YYYY-MM-DDTHH:MM:SS.SSSSS`).
|
||||
* Ze względu na przenośność kodu staraj się używać wyłącznie standardowych funkcji SQL
|
||||
zamiast funkcji specyficznych dla danego dostawcy silnika bazodanowego.
|
||||
* Kod powinien być zwięzły i pozbawiony zbędnego kodu SQL, np. bez zbędnych cudzysłowów,
|
||||
* Kod powinien być zwięzły i pozbawiony zbędnego kodu SQL, np. bez zbędnych cudzysłowów,
|
||||
nawiasów lub klauzul `WHERE`, które mogą być wyprowadzone w inny sposób.
|
||||
* Dodawaj komentarze do kodu SQL tam, gdzie jest to konieczne. Używaj komentarzy w stylu C,
|
||||
otwierając `/*` i zamykając `*/` je tam, gdzie jest to możliwe; w przeciwnym razie poprzedzaj
|
||||
|
|
@ -61,7 +61,7 @@ UPDATE file_system
|
|||
* Liczba mnoga – tam, gdzie jest to możliwe, używaj bardziej naturalnego określenia zbiorowego,
|
||||
np. `staff` zamiast `employees` lub `people` zamiast `individuals`.
|
||||
* Identyfikatory otoczone cudzysłowem/apostrofem – jeśli musisz ich używać, to w celu zachowania
|
||||
przenośności kodu trzymaj się standardu SQL-92, czyli stosuj cudzysłów (w zależności od
|
||||
przenośności kodu trzymaj się standardu SQL-92, czyli stosuj cudzysłów (w zależności od
|
||||
dostawcy silnika bazodanowego być może będziesz musiał dodatkowo skonfigurować swój serwer
|
||||
SQL).
|
||||
* Zasady projektowania obiektowego nie powinny być stosowane do kodu SQL i struktur bazy danych.
|
||||
|
|
@ -70,9 +70,9 @@ UPDATE file_system
|
|||
|
||||
### Ogólne
|
||||
|
||||
* Upewnij się, że nazwa jest unikalna i nie istnieje jako
|
||||
* Upewnij się, że nazwa jest unikalna i nie istnieje jako
|
||||
[zastrzeżone słowo kluczowe][reserved-keywords].
|
||||
* Nazwa powinna mieć rozmiar maksymalnie 30 bajtów – w praktyce jest to 30 znaków,
|
||||
* Nazwa powinna mieć rozmiar maksymalnie 30 bajtów – w praktyce jest to 30 znaków,
|
||||
chyba że używasz wielobajtowego zestawu znaków.
|
||||
* Nazwy muszą zaczynać się od litery i nie mogą kończyć się podkreślnikiem.
|
||||
* W nazwach należy używać tylko liter, cyfr i podkreślników.
|
||||
|
|
@ -88,13 +88,13 @@ SELECT first_name
|
|||
|
||||
### Tabele
|
||||
|
||||
* Używaj nazwy zbiorowej lub, w najgorszym przypadku, formy liczby mnogiej. Na przykład
|
||||
* Używaj nazwy zbiorowej lub, w najgorszym przypadku, formy liczby mnogiej. Na przykład
|
||||
(w kolejności preferencji) `staff` i `employees`.
|
||||
* Nie używaj przedrostka `tbl` ani żadnego innego opisowego przedrostka lub notacji
|
||||
* Nie używaj przedrostka `tbl` ani żadnego innego opisowego przedrostka lub notacji
|
||||
węgierskiej.
|
||||
* Nigdy nie nadawaj tabeli tej samej nazwy co jedna z jej kolumn i vice versa.
|
||||
* Jeśli to możliwe, to unikaj konkatenacji nazw dwóch tabel w celu utworzenia nazwy
|
||||
tabeli odzwierciedlającej związek między tymi tabelami. Zamiast `cars_mechanics`
|
||||
* Jeśli to możliwe, to unikaj konkatenacji nazw dwóch tabel w celu utworzenia nazwy
|
||||
tabeli odzwierciedlającej związek między tymi tabelami. Zamiast `cars_mechanics`
|
||||
wybierz `services`.
|
||||
|
||||
### Kolumny
|
||||
|
|
@ -111,7 +111,7 @@ SELECT first_name
|
|||
* Ogólną zasadą jest, że nazwa aliasu powinna być pierwszą literą każdego słowa z nazwy obiektu.
|
||||
* Jeśli istnieje już alias o tej samej nazwie, to dodaj do nazwy numer.
|
||||
* Zawsze dołączaj słowo kluczowe `AS` – ułatwia to czytanie, ponieważ jawnie definiuje alias.
|
||||
* Dla danych wyliczanych (`SUM()` lub `AVG()`) używaj nazwy, którą nadałbyś tej kolumnie,
|
||||
* Dla danych wyliczanych (`SUM()` lub `AVG()`) używaj nazwy, którą nadałbyś tej kolumnie,
|
||||
gdyby była zdefiniowana w schemacie.
|
||||
|
||||
```sql
|
||||
|
|
@ -128,13 +128,13 @@ SELECT SUM(s.monitor_tally) AS monitor_total
|
|||
### Procedury składowane
|
||||
|
||||
* Nazwa musi zawierać czasownik.
|
||||
* Nie należy jej poprzedzać przedrostkiem `sp_` ani żadnym innym podobnym przedrostkiem
|
||||
* Nie należy jej poprzedzać przedrostkiem `sp_` ani żadnym innym podobnym przedrostkiem
|
||||
opisowym lub notacją węgierską.
|
||||
|
||||
### Jednolite przyrostki
|
||||
|
||||
Poniższe przyrostki mają uniwersalne znaczenie, dzięki czemu można łatwo znaleźć kolumny
|
||||
w kodzie SQL i zrozumieć ich przeznaczenie. Używaj właściwego przyrostka tam, gdzie jest
|
||||
Poniższe przyrostki mają uniwersalne znaczenie, dzięki czemu można łatwo znaleźć kolumny
|
||||
w kodzie SQL i zrozumieć ich przeznaczenie. Używaj właściwego przyrostka tam, gdzie jest
|
||||
to stosowne.
|
||||
|
||||
* `_id` – unikalny identyfikator, np. kolumna będąca kluczem głównym.
|
||||
|
|
@ -152,10 +152,10 @@ to stosowne.
|
|||
|
||||
### Słowa zastrzeżone
|
||||
|
||||
Zawsze używaj dużych liter dla [zastrzeżonych słów kluczowych][reserved-keywords] takich jak
|
||||
Zawsze używaj dużych liter dla [zastrzeżonych słów kluczowych][reserved-keywords] takich jak
|
||||
`SELECT` i `WHERE`.
|
||||
|
||||
Najlepiej jest unikać skróconych słów kluczowych i używać ich pełnych nazw, oczywiście o ile
|
||||
Najlepiej jest unikać skróconych słów kluczowych i używać ich pełnych nazw, oczywiście o ile
|
||||
są dostępne (preferuj `ABSOLUTE` zamiast `ABS`).
|
||||
|
||||
Jeśli w specyfikacji ANSI SQL istnieje słowo kluczowe realizujące żądaną operację,
|
||||
|
|
@ -170,14 +170,14 @@ SELECT model_num
|
|||
|
||||
### Białe znaki
|
||||
|
||||
Aby kod był łatwiejszy do odczytania, należy używać odpowiednich odstępów między
|
||||
Aby kod był łatwiejszy do odczytania, należy używać odpowiednich odstępów między
|
||||
wyrażeniami. Nie zagęszczaj kodu ani nie usuwaj spacji, które występują w języku naturalnym.
|
||||
|
||||
#### Spacje
|
||||
|
||||
Spacje powinny być użyte do ułożenia kodu w taki sposób, aby główne słowa kluczowe kończyły
|
||||
się na tej samej granicy znaków. Tworzy to pośrodku kodu tzw. rzekę, ułatwiając oku czytelnika
|
||||
przeglądanie kodu i oddzielenie słów kluczowych od szczegółów implementacji. Rzeki zasadniczo
|
||||
przeglądanie kodu i oddzielenie słów kluczowych od szczegółów implementacji. Rzeki zasadniczo
|
||||
są [złe w typografii][rivers], ale tutaj okazują się pomocne.
|
||||
|
||||
```sql
|
||||
|
|
@ -200,7 +200,7 @@ są [złe w typografii][rivers], ale tutaj okazują się pomocne.
|
|||
GROUP BY b.species_name, b.observation_date);
|
||||
```
|
||||
|
||||
Zauważ, że `SELECT`, `FROM` itp. są wyrównane do prawej, podczas gdy nazwy kolumn i szczegóły
|
||||
Zauważ, że `SELECT`, `FROM` itp. są wyrównane do prawej, podczas gdy nazwy kolumn i szczegóły
|
||||
specyficzne dla implementacji są wyrównane do lewej.
|
||||
|
||||
Choć nie jest to lista wyczerpująca, zawsze umieszczaj spacje:
|
||||
|
|
@ -227,7 +227,7 @@ Zawsze dodawaj nowe linie/odstęp pionowy:
|
|||
* po przecinku przy rozdzielaniu wielu kolumn na grupy logiczne,
|
||||
* aby rozdzielić kod na powiązane sekcje, co zwiększa czytelności dużych fragmentów kodu.
|
||||
|
||||
Utrzymanie wszystkich słów kluczowych wyrównanych do prawej strony, a wartości wyrównanych
|
||||
Utrzymanie wszystkich słów kluczowych wyrównanych do prawej strony, a wartości wyrównanych
|
||||
do lewej, tworzy jednolitą przerwę pośrodku zapytania. Ułatwia to również szybkie przeglądanie
|
||||
definicji zapytania.
|
||||
|
||||
|
|
@ -274,8 +274,8 @@ SELECT r.last_name
|
|||
#### Podzapytania
|
||||
|
||||
Podzapytania również powinny być wyrównane do prawej strony rzeki, a następnie ułożone w tym
|
||||
samym stylu, co każde inne zapytanie. Czasami można umieścić nawias zamykający w nowej linii,
|
||||
na tej samej pozycji co towarzyszący mu nawias otwierający – ma to szczególne zastosowanie
|
||||
samym stylu, co każde inne zapytanie. Czasami można umieścić nawias zamykający w nowej linii,
|
||||
na tej samej pozycji co towarzyszący mu nawias otwierający – ma to szczególne zastosowanie
|
||||
w przypadku podzapytań zagnieżdżonych.
|
||||
|
||||
```sql
|
||||
|
|
@ -296,9 +296,9 @@ SELECT r.last_name,
|
|||
|
||||
* Używaj `BETWEEN` tam, gdzie jest to możliwe, zamiast łączyć wiele wyrażeń przy pomocy `AND`.
|
||||
* Podobnie używaj `IN()` zamiast wielu `OR`.
|
||||
* Używaj wyrażeń `CASE` zamiast skomplikowanych predykatów z dużą liczbą nawiasów. Wyrażenia
|
||||
* Używaj wyrażeń `CASE` zamiast skomplikowanych predykatów z dużą liczbą nawiasów. Wyrażenia
|
||||
`CASE` mogą być zagnieżdżane w celu uzyskania bardziej złożonych struktur logicznych.
|
||||
* Unikaj stosowania klauzul `UNION` i tabel tymczasowych, o ile to możliwe. Jeśli schemat może
|
||||
* Unikaj stosowania klauzul `UNION` i tabel tymczasowych, o ile to możliwe. Jeśli schemat może
|
||||
być zoptymalizowany tak, aby nie zależał od tych elementów SQL-a, to najprawdopodobniej
|
||||
powinien zostać zoptymalizowany.
|
||||
|
||||
|
|
@ -315,16 +315,16 @@ SELECT CASE postcode
|
|||
|
||||
## Składnia tworzenia obiektów
|
||||
|
||||
Podczas deklarowania informacji o schemacie ważne jest również zapewnienie czytelnego kodu.
|
||||
Aby to uzyskać, upewnij się, że definicje kolumn są uporządkowane i pogrupowane razem
|
||||
Podczas deklarowania informacji o schemacie ważne jest również zapewnienie czytelnego kodu.
|
||||
Aby to uzyskać, upewnij się, że definicje kolumn są uporządkowane i pogrupowane razem
|
||||
w tych miejscach, gdzie ma to sens.
|
||||
|
||||
W poleceniu `CREATE` w definicjach kolumn stosuj cztery (4) spacje.
|
||||
|
||||
### Wybór typów danych
|
||||
|
||||
* Jeśli to możliwe, nie używaj typów danych specyficznych dla dostawcy silnika
|
||||
bazodanowego – nie są one przenośne i mogą nie być dostępne w starszych wersjach
|
||||
* Jeśli to możliwe, nie używaj typów danych specyficznych dla dostawcy silnika
|
||||
bazodanowego – nie są one przenośne i mogą nie być dostępne w starszych wersjach
|
||||
oprogramowania tego samego dostawcy.
|
||||
* Używaj typów `REAL` lub `FLOAT` tylko wtedy, gdy jest to absolutnie konieczne dla obliczeń
|
||||
zmiennoprzecinkowych; w przeciwnym razie zawsze preferuj typy `NUMERIC` i `DECIMAL`. Błędy
|
||||
|
|
@ -356,9 +356,9 @@ starannie przemyślane, ponieważ będzie miało to wpływ na wydajność i inte
|
|||
4. Utrzymanie klucza tak prostego, jak to tylko możliwe, ale nie bójmy się używać kluczy
|
||||
złożonych, gdy jest to konieczne.
|
||||
|
||||
Powyższe rozważania to uzasadnione i przemyślane działania, które należy wykonać podczas
|
||||
Powyższe rozważania to uzasadnione i przemyślane działania, które należy wykonać podczas
|
||||
definiowania bazy danych i mają za zadanie rozważyć wszystkie za i przeciw. Jeśli wymagania
|
||||
będą w przyszłości się zmieniały, to możliwe jest wprowadzenie zmian w definicjach, tak aby
|
||||
będą w przyszłości się zmieniały, to możliwe jest wprowadzenie zmian w definicjach, tak aby
|
||||
zachować ich aktualność.
|
||||
|
||||
#### Definiowanie ograniczeń
|
||||
|
|
@ -369,18 +369,18 @@ wraz z weryfikowaniem wartości pól.
|
|||
##### Ogólne
|
||||
|
||||
* Tabele, aby były kompletne i użyteczne, muszą posiadać co najmniej jeden klucz.
|
||||
* Ograniczenia powinny mieć własną nazwę, z wyjątkiem `UNIQUE`, `PRIMARY KEY` i `FOREIGN KEY`,
|
||||
w których dostawca silnika bazy danych zazwyczaj automatycznie generuje wystarczająco
|
||||
* Ograniczenia powinny mieć własną nazwę, z wyjątkiem `UNIQUE`, `PRIMARY KEY` i `FOREIGN KEY`,
|
||||
w których dostawca silnika bazy danych zazwyczaj automatycznie generuje wystarczająco
|
||||
zrozumiałe nazwy.
|
||||
|
||||
##### Układ i kolejność
|
||||
|
||||
* Określ klucz główny jako pierwszy zaraz po instrukcji `CREATE TABLE`.
|
||||
* Ograniczenia powinny być zdefiniowane bezpośrednio pod kolumną, której odpowiadają.
|
||||
* Ograniczenia powinny być zdefiniowane bezpośrednio pod kolumną, której odpowiadają.
|
||||
Wyrównaj wcięciami ograniczenie tak, aby wyrównać do prawej strony nazwy kolumny.
|
||||
* Jeśli ograniczenie dotyczy wielu kolumn, rozważ umieszczenie go jak najbliżej definicji obu
|
||||
kolumn, a jeśli jest to trudne, to w ostateczności umieść je na końcu definicji `CREATE TABLE`.
|
||||
* Jeśli ograniczenie odnosi się do całej tabeli, to również powinno pojawić się na końcu
|
||||
* Jeśli ograniczenie odnosi się do całej tabeli, to również powinno pojawić się na końcu
|
||||
definicji `CREATE TABLE`.
|
||||
* Użyj kolejności alfabetycznej, tak aby `ON DELETE` było przed `ON UPDATE`.
|
||||
* Jeśli ma to sens, to umieść każdy element zapytania na tej samej pozycji; np. wszystkie
|
||||
|
|
@ -416,14 +416,14 @@ CREATE TABLE staff (
|
|||
* Zasady projektowania obiektowego nie przekładają się efektywnie na projekty relacyjnych baz
|
||||
danych – unikaj tej pułapki.
|
||||
* Umieszczanie wartości w jednej kolumnie, a jednostek w drugiej. Kolumna powinna czynić jednostki
|
||||
oczywistymi, dzięki czemu unikniemy wymogu ponownego łączenia kolumn w dalszej części
|
||||
oczywistymi, dzięki czemu unikniemy wymogu ponownego łączenia kolumn w dalszej części
|
||||
aplikacji. Używaj `CHECK()` aby upewnić się, że do kolumny są wstawiane poprawne dane.
|
||||
* Tabele typu [Encja-Atrybut-Wartość][eav] (ang. *Entity–Attribute–Value*, EAV) – zamiast tego
|
||||
użyj specjalistycznego produktu przeznaczonego do obsługi tego typu danych, które nie
|
||||
użyj specjalistycznego produktu przeznaczonego do obsługi tego typu danych, które nie
|
||||
posiadają schematu.
|
||||
* Rozdzielanie danych, które powinny znajdować się w jednej tabeli, na wiele tabel z powodu
|
||||
arbitralnych decyzji, np. z powodu archiwizacji według czasu lub lokalizacji geograficznej w
|
||||
międzynarodowej organizacji. Późniejsze zapytania muszą wtedy pracować na wielu tabelach przy
|
||||
* Rozdzielanie danych, które powinny znajdować się w jednej tabeli, na wiele tabel z powodu
|
||||
arbitralnych decyzji, np. z powodu archiwizacji według czasu lub lokalizacji geograficznej w
|
||||
międzynarodowej organizacji. Późniejsze zapytania muszą wtedy pracować na wielu tabelach przy
|
||||
pomocy `UNION`, zamiast po prostu odpytywać jedną tabelę.
|
||||
|
||||
## Dodatek
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ UPDATE file_system
|
|||
* Mantenha o tamanho máximo em 30 bytes—na prática isso são
|
||||
30 caracteres, a não ser que esteja utilizando um conjunto de
|
||||
caracteres multi-byte.
|
||||
* Nomes devem começar com uma letra e não devem terminar com underscore.
|
||||
* Nomes devem começar com uma letra e não devem terminar com underscore.
|
||||
* Utilize apenas letras, números e underscores em nomes.
|
||||
* Evite o uso de múltiplos underscores consecutivos—eles podem ser difíceis de
|
||||
se ler.
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Bu rehberi bir projenin kod tabanının bir parçası olarak [Markdown
|
|||
formatında][dl-md] eklemek veya projedeki herkesin özgürce okuması için burada
|
||||
referans vermek kolaydır - fiziksel bir kitapla bu çok daha zordur.
|
||||
|
||||
[Simon Holywell][simon] tarafından hazırlanan bu SQL stil rehberi [Creative Commons
|
||||
[Simon Holywell][simon] tarafından hazırlanan bu SQL stil rehberi [Creative Commons
|
||||
Attribution-ShareAlike 4.0 International License][licence] lisansı ile lisanslanmıştır.
|
||||
[https://www.sqlstyle.guide/][sqlstyleguide]'daki çalışmaya dayanarak.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,20 +1,20 @@
|
|||
# Посібник зі стиль-коду SQL
|
||||
|
||||
## Передмова
|
||||
Ви можете використовувати цей посібник, [зробити його форк][fork] або створити власний на його основі.
|
||||
Ви можете використовувати цей посібник, [зробити його форк][fork] або створити власний на його основі.
|
||||
Ціль - визначити, який стиль ваи підходить більше і дотримуватись його.
|
||||
Щоб запропонувати зміни або виправити помилки, відкрийте [задачу][issue] або [запит на витяг][pull] на GitHub.
|
||||
|
||||
Ці рекомендації розроблені таким чином, щоб вони були сумісні з книгою Joe Celko's [SQL Programming Style][celko],
|
||||
щоб її легше засвоїли команди, які вже прочитали цю книгу.
|
||||
Цей посібник є дещо категоричний у деяких твердженнях, а в інших вільніший.
|
||||
Він, безумовно, більш стислий, ніж [книга Celko][celko], яка містить анекдоти
|
||||
Ці рекомендації розроблені таким чином, щоб вони були сумісні з книгою Joe Celko's [SQL Programming Style][celko],
|
||||
щоб її легше засвоїли команди, які вже прочитали цю книгу.
|
||||
Цей посібник є дещо категоричний у деяких твердженнях, а в інших вільніший.
|
||||
Він, безумовно, більш стислий, ніж [книга Celko][celko], яка містить анекдоти
|
||||
та міркування за кожним правилом як продуману прозу.
|
||||
|
||||
Цей посібник легко включити у [форматі Markdown][dl-md] як частину кодової бази проекту або залишити посилання тут,
|
||||
Цей посібник легко включити у [форматі Markdown][dl-md] як частину кодової бази проекту або залишити посилання тут,
|
||||
щоб усі, хто бере участь у проекті, могли вільно його читати, що набагато складніше зробити з фізичною книгою.
|
||||
|
||||
SQL посібник зі стиль-коду авторства [Simon Holywell][simon] під ліцензією [Creative Commons
|
||||
SQL посібник зі стиль-коду авторства [Simon Holywell][simon] під ліцензією [Creative Commons
|
||||
Attribution-ShareAlike 4.0 International License][licence].
|
||||
Базується на роботі [https://www.sqlstyle.guide/][sqlstyleguide].
|
||||
|
||||
|
|
@ -26,9 +26,9 @@ Attribution-ShareAlike 4.0 International License][licence].
|
|||
* Розумно використовуйте пробіли і відступи, щоб полегшити читання коду;
|
||||
* Зберігайте інформацію про час і дату відповідно до [ISO 8601][iso-8601] (`YYYY-MM-DDTHH:MM:SS.SSSSS`);
|
||||
* З міркувань портативності намагайтеся використовувати лише стандартні функції SQL замість функцій постачальника;
|
||||
* Зробіть код стислим і позбавленим зайвого SQL, наприклад, непотрібних лапок або дужок або речень `WHERE`,
|
||||
* Зробіть код стислим і позбавленим зайвого SQL, наприклад, непотрібних лапок або дужок або речень `WHERE`,
|
||||
які можна отримати інакше;
|
||||
* Включіть коментарі в код SQL, де це необхідно. Використовуйте відкриваючий `/*` у стилі C і закриваючи `*/`,
|
||||
* Включіть коментарі в код SQL, де це необхідно. Використовуйте відкриваючий `/*` у стилі C і закриваючи `*/`,
|
||||
якщо це можливо, інакше перед коментарями ставте `--` і закінчуйте їх новим рядком.
|
||||
|
||||
```sql
|
||||
|
|
@ -49,9 +49,9 @@ UPDATE file_system
|
|||
|
||||
* camelCase — важко швидко сканувати.
|
||||
* Описові префікси або Угорська нотація, такі як `sp_` або `tbl`.
|
||||
* Множина — замість цього використовуйте більш природний збірний термін, де це можливо.
|
||||
* Множина — замість цього використовуйте більш природний збірний термін, де це можливо.
|
||||
Наприклад, `staff` замість `employees` або `people` замість `individuals`.
|
||||
* Ідентифікатори в лапках — якщо вам потрібно їх використовувати, то для переносимості дотримуйтеся подвійних лапок
|
||||
* Ідентифікатори в лапках — якщо вам потрібно їх використовувати, то для переносимості дотримуйтеся подвійних лапок
|
||||
SQL-92 (можливо, вам доведеться налаштувати свій SQL-сервер для підтримки цього в залежності від постачальника).
|
||||
* Принципи об'єктно-орієнтованого проектування не повинні застосовуватися до SQL або структур баз даних.
|
||||
|
||||
|
|
@ -60,14 +60,14 @@ UPDATE file_system
|
|||
### Загальне
|
||||
|
||||
* Переконайтеся, що ім'я є унікальним і не являється [зарезервованим ключовим словом][reserved-keywords].
|
||||
* Максимальна довжина становить 30 байт — на практиці це 30 символів,
|
||||
* Максимальна довжина становить 30 байт — на практиці це 30 символів,
|
||||
якщо ви не використовуєте багатобайтовий набір символів.
|
||||
* Імена повинні починатися з літери і не можуть закінчуватися символом підкреслення.
|
||||
* Використовуйте лише літери, цифри та підкреслення в іменах.
|
||||
* Уникайте використання кількох послідовних символів підкреслення — їх важко прочитати.
|
||||
* Використовуйте символи підкреслення там, де ви, природно, включили б пробіл в назву
|
||||
* Використовуйте символи підкреслення там, де ви, природно, включили б пробіл в назву
|
||||
(наприклад ім’я буде `first_name`).
|
||||
* Уникайте скорочень, і якщо вам потрібно їх використовувати, переконайтеся,
|
||||
* Уникайте скорочень, і якщо вам потрібно їх використовувати, переконайтеся,
|
||||
що вони зрозумілі або широко використовувані.
|
||||
|
||||
```sql
|
||||
|
|
@ -80,13 +80,13 @@ SELECT first_name
|
|||
* Використовуйте збірну назву або, менш ідеально, форму множини. Наприклад (у порядку переваги) `staff` і `employees`.
|
||||
* Не використовуйте префікс `tbl` або будь-який інший такий описовий префікс або Угорську нотацію.
|
||||
* Ніколи не давайте таблиці таку саму назву, що й один із її стовпців, і навпаки.
|
||||
* Уникайте, де це можливо, об’єднання двох імен таблиць разом, щоб створити назву таблиці зв’язків.
|
||||
* Уникайте, де це можливо, об’єднання двох імен таблиць разом, щоб створити назву таблиці зв’язків.
|
||||
Замість `cars_mechanics` віддають перевагу `services`.
|
||||
|
||||
### Стовпці
|
||||
|
||||
* Завжди використовуйте назву в однині.
|
||||
* По можливості уникайте простого використання `id` як основного ідентифікатора для таблиці
|
||||
* По можливості уникайте простого використання `id` як основного ідентифікатора для таблиці
|
||||
(або використовуйте конвенції прийняті спільнотою).
|
||||
* Не додавайте стовпець з такою ж назвою, що й таблиця, і навпаки.
|
||||
* Завжди використовуйте нижній регістр, за винятком тих випадків, коли це може мати сенс, наприклад, власні назви.
|
||||
|
|
@ -97,7 +97,7 @@ SELECT first_name
|
|||
* Як правило, ім'я кореляції має бути першою літерою кожного слова в назві об'єкта.
|
||||
* Якщо вже існує кореляція з такою ж назвою, додайте число.
|
||||
* Завжди включайте ключове слово `AS` — полегшує читання, оскільки воно є явним.
|
||||
* Для обчислюваних даних (`SUM()` або` AVG()`) використовуйте ім’я,
|
||||
* Для обчислюваних даних (`SUM()` або` AVG()`) використовуйте ім’я,
|
||||
яке ви б дали їм, якби цей стовпець був визначений у схемі.
|
||||
|
||||
```sql
|
||||
|
|
@ -119,7 +119,7 @@ SELECT SUM(s.monitor_tally) AS monitor_total
|
|||
|
||||
### Однорідні суфікси
|
||||
|
||||
Наступні суфікси мають універсальне значення, що забезпечує легке читання та розуміння стовпців із коду SQL.
|
||||
Наступні суфікси мають універсальне значення, що забезпечує легке читання та розуміння стовпців із коду SQL.
|
||||
Використовуйте правильний суфікс, де це доречно.
|
||||
|
||||
* `_id` — унікальний ідентифікатор, наприклад стовпець, який є первинним ключем;
|
||||
|
|
@ -139,11 +139,11 @@ SELECT SUM(s.monitor_tally) AS monitor_total
|
|||
|
||||
Завжди використовуйте верхній регістр для [зарезервованих ключових слів][reserved-keywords], як-от `SELECT` і `WHERE`.
|
||||
|
||||
Найкраще уникати скорочених ключових слів і використовувати повні ключові слова,
|
||||
Найкраще уникати скорочених ключових слів і використовувати повні ключові слова,
|
||||
якщо вони доступні (віддавайте перевагу `ABSOLUTE` замість `ABS`).
|
||||
|
||||
Не використовуйте ключові слова, специфічні для сервера баз даних,
|
||||
якщо ключове слово ANSI SQL вже існує і виконує ту ж функцію.
|
||||
Не використовуйте ключові слова, специфічні для сервера баз даних,
|
||||
якщо ключове слово ANSI SQL вже існує і виконує ту ж функцію.
|
||||
Це допомагає зробити код більш переносимим.
|
||||
|
||||
```sql
|
||||
|
|
@ -154,15 +154,15 @@ SELECT model_num
|
|||
|
||||
### Порожній простір
|
||||
|
||||
Для полегшення читання коду важливо використовувати правильне доповнення пробілів.
|
||||
Для полегшення читання коду важливо використовувати правильне доповнення пробілів.
|
||||
Не переповнюйте код і не видаляйте пробіли природної мови.
|
||||
|
||||
#### Пробіли
|
||||
|
||||
Для вибудовування коду потрібно використовувати пробіли,
|
||||
Для вибудовування коду потрібно використовувати пробіли,
|
||||
щоб усі ключові слова кореня закінчувалися на одній межі символу.
|
||||
Це утворює додатковий простір посередині, що дозволяє читачам легко переглядати код
|
||||
і відокремлювати ключові слова від деталей реалізації.
|
||||
Це утворює додатковий простір посередині, що дозволяє читачам легко переглядати код
|
||||
і відокремлювати ключові слова від деталей реалізації.
|
||||
Такі відступи [небажані в типографії][rivers], але тут корисні.
|
||||
|
||||
```sql
|
||||
|
|
@ -185,14 +185,14 @@ SELECT model_num
|
|||
GROUP BY b.species_name, b.observation_date);
|
||||
```
|
||||
|
||||
Зверніть увагу, що `SELECT`, `FROM` тощо вирівнюються по правому краю,
|
||||
Зверніть увагу, що `SELECT`, `FROM` тощо вирівнюються по правому краю,
|
||||
а фактичні назви стовпців та конкретні відомості щодо реалізації вирівнюються за лівим краєм.
|
||||
|
||||
Хоча цей список не вичерпний, завжди включайте пробіли:
|
||||
|
||||
* до і після знака "дорівнює" (`=`);
|
||||
* після коми (`,`);
|
||||
* до відкриваючого і після закриваючого апострофів (`` ` ``),
|
||||
* до відкриваючого і після закриваючого апострофів (`` ` ``),
|
||||
за умови, що вони не в дужках, не з комою та не крапкою з комою;
|
||||
|
||||
```sql
|
||||
|
|
@ -212,7 +212,7 @@ SELECT a.title, a.release_date, a.recording_date
|
|||
* після коми при розділенні кількох стовпців на логічні групи;
|
||||
* щоб розділити код на пов'язані розділи, що полегшує читання великих фрагментів коду;
|
||||
|
||||
Якщо всі ключові слова вирівняні по праву сторону, а значення по праву сторону -
|
||||
Якщо всі ключові слова вирівняні по праву сторону, а значення по праву сторону -
|
||||
у середині запиту створюється рівномірний простір, що також значно полегшує швидке читання та сканування запиту.
|
||||
|
||||
```sql
|
||||
|
|
@ -257,9 +257,9 @@ SELECT r.last_name
|
|||
|
||||
#### Підзапити
|
||||
|
||||
Підзапити також мають бути вирівняні по праву сторону з додатковим відступом,
|
||||
Підзапити також мають бути вирівняні по праву сторону з додатковим відступом,
|
||||
а потім викладені у такому ж стилі, що й будь-який інший запит.
|
||||
Іноді має сенс мати закриваючу дужку на новому рядку в тій самій позиції символу, що й його початковий партнер.
|
||||
Іноді має сенс мати закриваючу дужку на новому рядку в тій самій позиції символу, що й його початковий партнер.
|
||||
Це особливо зручно, якщо у вас є вкладені підзапити.
|
||||
|
||||
```sql
|
||||
|
|
@ -280,10 +280,10 @@ SELECT r.last_name,
|
|||
|
||||
* Використовуйте `BETWEEN`, де це можливо, замість того, щоб об'єднувати кілька операторів з `AND`.
|
||||
* Аналогічно використовуйте `IN()` замість кількох пропозицій `OR`.
|
||||
* Якщо значення потрібно інтерпретувати/перетворити перед тим, як воно стане частиною результату,
|
||||
* Якщо значення потрібно інтерпретувати/перетворити перед тим, як воно стане частиною результату,
|
||||
використовуйте оператор `CASE`.
|
||||
Оператори `CASE` можуть бути вкладені для формування більш складних логічних структур.
|
||||
* Уникайте використання оператора `UNION` і тимчасових таблиць, де це можливо.
|
||||
* Уникайте використання оператора `UNION` і тимчасових таблиць, де це можливо.
|
||||
Якщо схему можна оптимізувати, щоб виключити залежність від цих функцій, то, швидше за все, так і буде.
|
||||
|
||||
```sql
|
||||
|
|
@ -299,44 +299,44 @@ SELECT CASE postcode
|
|||
|
||||
## Синтаксис створення
|
||||
|
||||
При оголошенні структури схеми також важливо підтримувати зрозумілий для людини код.
|
||||
При оголошенні структури схеми також важливо підтримувати зрозумілий для людини код.
|
||||
Щоб полегшити це, переконайтеся, що визначення стовпців упорядковані та згруповані разом, де це має сенс.
|
||||
|
||||
Відступ у визначенні стовпців на чотири (4) пробіли у визначенні `CREATE`.
|
||||
|
||||
### Вибір типів даних
|
||||
|
||||
* Якщо можливо, не використовуйте типи даних специфічні для вашої СУБД —
|
||||
* Якщо можливо, не використовуйте типи даних специфічні для вашої СУБД —
|
||||
вони не є переносними і можуть бути недоступними в старіших версіях СУБД того самого постачальника.
|
||||
* Використовуйте типи `REAL` або `FLOAT` лише там, де це необхідно для математики з плаваючою комою,
|
||||
інакше завжди віддавайте перевагу `NUMERIC` та `DECIMAL`.
|
||||
інакше завжди віддавайте перевагу `NUMERIC` та `DECIMAL`.
|
||||
Помилки округлення з плаваючою комою є неприємністю!
|
||||
|
||||
### Визначення значень за замовчуванням
|
||||
|
||||
* Значення за замовчуванням має бути того самого типу, що й стовпець —
|
||||
* Значення за замовчуванням має бути того самого типу, що й стовпець —
|
||||
якщо стовпець оголошено як `DECIMAL`, не надавайте значення за замовчуванням `INTEGER`.
|
||||
* Оголошення значення за замовчуванням має знаходитись
|
||||
* Оголошення значення за замовчуванням має знаходитись
|
||||
після оголошення типу даних і перед будь-яким оператором `NOT NULL`.
|
||||
|
||||
### Обмеження та ключі
|
||||
|
||||
Обмеження та їх підмножина, ключі, є дуже важливим компонентом будь-якого визначення бази даних.
|
||||
Вони швидко можуть стати дуже складними для читання та роздумів,
|
||||
Обмеження та їх підмножина, ключі, є дуже важливим компонентом будь-якого визначення бази даних.
|
||||
Вони швидко можуть стати дуже складними для читання та роздумів,
|
||||
тому важливо дотримуватися стандартного набору вказівок.
|
||||
|
||||
#### Вибір ключів
|
||||
|
||||
Вибір стовпців, які формуватимуть ключі у визначенні, має бути ретельно продуманим,
|
||||
Вибір стовпців, які формуватимуть ключі у визначенні, має бути ретельно продуманим,
|
||||
оскільки це вплине на продуктивність та цілісність даних.
|
||||
|
||||
1. До певної міри ключ повинен бути унікальним.
|
||||
2. Узгодженість з точки зору типу даних для значеннь в схемі та менша ймовірність того, що це зміниться в майбутньому.
|
||||
3. Чи можна перевіряти значення відповідно до стандартного формату (наприклад, опублікованого ISO)?
|
||||
3. Чи можна перевіряти значення відповідно до стандартного формату (наприклад, опублікованого ISO)?
|
||||
Заохочення відповідності пункту 2.
|
||||
4. Зберігайте ключ якомога простим, не боячись використовувати складні ключі, де це необхідно.
|
||||
|
||||
Це обгрунтований і зважений акт балансування, який необхідно виконати при визначенні бази даних.
|
||||
Це обгрунтований і зважений акт балансування, який необхідно виконати при визначенні бази даних.
|
||||
Якщо вимоги зміняться в майбутньому, можна внести зміни до визначень, щоб підтримувати їх в актуальному стані.
|
||||
|
||||
#### Визначення обмежень
|
||||
|
|
@ -346,29 +346,29 @@ SELECT CASE postcode
|
|||
##### Загальне
|
||||
|
||||
* Щоб таблиці були повними та корисними, вони повинні мати принаймні один ключ.
|
||||
* Обмеженням слід присвоювати користувацькі назви, за винятком `UNIQUE`, `PRIMARY KEY` та `FOREIGN KEY`,
|
||||
* Обмеженням слід присвоювати користувацькі назви, за винятком `UNIQUE`, `PRIMARY KEY` та `FOREIGN KEY`,
|
||||
яким постачальник бази даних, як правило, автоматично надає достатньо зрозумілі імена.
|
||||
|
||||
##### Макет і порядок
|
||||
|
||||
* Спочатку вкажіть первинний ключ відразу після оператора `CREATE TABLE`.
|
||||
* Обмеження слід визначити безпосередньо під стовпцем, якому вони відповідають.
|
||||
* Обмеження слід визначити безпосередньо під стовпцем, якому вони відповідають.
|
||||
Зробіть відступ обмеження, щоб воно вирівнялося праворуч від імені стовпця.
|
||||
* Якщо це обмеження для кількох стовпців, подумайте про те,
|
||||
щоб розмістити його якомога ближче до визначень обох стовпців, а якщо це важко, в крайньому випадку,
|
||||
* Якщо це обмеження для кількох стовпців, подумайте про те,
|
||||
щоб розмістити його якомога ближче до визначень обох стовпців, а якщо це важко, в крайньому випадку,
|
||||
включіть їх у кінці визначення `CREATE TABLE`.
|
||||
* Якщо це обмеження на рівні таблиці, яке застосовується до всієї таблиці, воно також має відображатися в кінці.
|
||||
* Використовуйте алфавітний порядок, щоб `ON DELETE` розміщувалось перед `ON UPDATE`.
|
||||
* Якщо це має сенс, вирівняйте кожен аспект запиту на одній позиції символу.
|
||||
Наприклад, усі визначення `NOT NULL` можуть починатися з однієї позиції символу.
|
||||
* Якщо це має сенс, вирівняйте кожен аспект запиту на одній позиції символу.
|
||||
Наприклад, усі визначення `NOT NULL` можуть починатися з однієї позиції символу.
|
||||
Це не важко і швидко, але, безумовно, значно полегшує сканування та читання коду.
|
||||
|
||||
##### Валідація
|
||||
|
||||
* Використовуйте обмеження `LIKE` і `SIMILAR TO`, щоб забезпечити цілісність рядків, формат яких відомий.
|
||||
* Якщо відомий кінцевий діапазон числового значення, його потрібно записати як діапазон `CHECK()`,
|
||||
щоб запобігти введенню неправильних значень у базу даних або непомченого скорочення даних,
|
||||
занадто великих, щоб відповідати визначенню стовпця.
|
||||
* Якщо відомий кінцевий діапазон числового значення, його потрібно записати як діапазон `CHECK()`,
|
||||
щоб запобігти введенню неправильних значень у базу даних або непомченого скорочення даних,
|
||||
занадто великих, щоб відповідати визначенню стовпця.
|
||||
Щонайменше, він повинен перевірити, що значення більше нуля в більшості випадків.
|
||||
* Обмеження `CHECK()` слід зберігати в окремих пунктах, щоб полегшити налагодження.
|
||||
|
||||
|
|
@ -388,20 +388,20 @@ CREATE TABLE staff (
|
|||
### Дизайни, яких слід уникати
|
||||
|
||||
* Не використовуйте принципи об'єктно-орієнтованого проектування - вони не оптимальні для реляційних баз даних .
|
||||
* Не розміщуйте значення в одному стовпці та одиниці вимірювання в іншому.
|
||||
Стовпець має бути очевидними та самодокументованим, щоб запобігти потребі об’єднувати стовпці в програмі пізніше.
|
||||
* Не розміщуйте значення в одному стовпці та одиниці вимірювання в іншому.
|
||||
Стовпець має бути очевидними та самодокументованим, щоб запобігти потребі об’єднувати стовпці в програмі пізніше.
|
||||
Використовуйте `CHECK()`, щоб переконатися, що коректні дані вставлені в стовпець.
|
||||
* Не використовуйте паттерн [Entity–Attribute–Value][eav] (EAV) — замість цього використовуйте спеціалізовані продукти,
|
||||
* Не використовуйте паттерн [Entity–Attribute–Value][eav] (EAV) — замість цього використовуйте спеціалізовані продукти,
|
||||
призначені для обробки таких даних без схем.
|
||||
* Не розділяйте дані, які мають бути в одній таблиці, на багато таблиць через довільні проблеми,
|
||||
такі як архівування на основі часу або розташування в багатонаціональній організації.
|
||||
Пізніші доведеться працювати з кількома таблицями через `UNION`, замість простих запитів в одну таблицю.
|
||||
* Не розділяйте дані, які мають бути в одній таблиці, на багато таблиць через довільні проблеми,
|
||||
такі як архівування на основі часу або розташування в багатонаціональній організації.
|
||||
Пізніші доведеться працювати з кількома таблицями через `UNION`, замість простих запитів в одну таблицю.
|
||||
|
||||
## Додаток
|
||||
|
||||
### Посилання на зарезервовані ключові слова
|
||||
|
||||
Список зарезервованих ключових слів ANSI SQL (92, 99 і 2003), MySQL 3–5.x, PostgreSQL 8.1, MS SQL Server 2000, MS ODBC
|
||||
Список зарезервованих ключових слів ANSI SQL (92, 99 і 2003), MySQL 3–5.x, PostgreSQL 8.1, MS SQL Server 2000, MS ODBC
|
||||
та Oracle 10.2.
|
||||
|
||||
```sql
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Những quy tắc này tương đồng với những gì được đề cập t
|
|||
|
||||
Bạn có thể dễ dàng đặt bộ quy tắc này ở [định dạng Markdown][dl-md] vào thẳng thư mục code của dự án hoặc chỉ đơn giản là đặt tham chiếu tới đây để nếu ai muốn thì có thể tìm đọc phiên bản sách giấy.
|
||||
|
||||
Bộ quy tắc viết câu lệnh SQL này được tạo ra bởi [Simon Holywell][simon] và được bảo vệ bằng giấy phép [Creative Commons Attribution-ShareAlike 4.0 International][licence].
|
||||
Bộ quy tắc viết câu lệnh SQL này được tạo ra bởi [Simon Holywell][simon] và được bảo vệ bằng giấy phép [Creative Commons Attribution-ShareAlike 4.0 International][licence].
|
||||
Có tham khảo [https://www.sqlstyle.guide/][sqlstyleguide].
|
||||
|
||||
## Những quy tắc chung
|
||||
|
|
|
|||
Loading…
Reference in a new issue