Czy istnieje dobry powód, aby używać wielkich liter w słowach kluczowych SQL? [Zamknięte]

128

Domyślnie wydaje się, że są to wielkie litery, ale czy naprawdę jest jakiś powód, aby używać wielkich liter w słowach kluczowych? Zacząłem używać wielkich liter, ponieważ próbowałem dopasować to, co daje mi SQL Server, za każdym razem, gdy próbowałem coś utworzyć, na przykład nową procedurę składowaną. Ale potem poczułem się okropnie z powodu mojego małego (piątego) palca, który zawsze musi przytrzymywać Shiftprzycisk, więc przestałem używać wielkich liter. Czy jest jakiś powód, dla którego powinienem wracać do wielkich liter?

Edycja : Dzięki za odpowiedzi. Nie programowałem jeszcze w czasach, gdy COBOL był królem, więc nie byłem tego świadomy. Od teraz będę trzymał się małych liter.

Hertanto Lie
źródło
9
Spróbuj użyć klawisza CAPS LOCK. :)
MusiGenesis
7
Nadal muszę włączyć CAPS LOCK, gdy chcę pisać słowa kluczowe, a następnie wyłączyć, gdy nie piszę słów kluczowych, i ponownie włączyć CAPS LOCK i tak dalej, i tak dalej. To tylko kłopot.
Hertanto Lie
17
CAPS co ... Och, masz na myśli mój trzeci klawisz Ctrl?
Dave Sherohman
2
IIRC, zabawne jest to, że jeśli sprawdzisz procedury sp_ w MSSQL, wszystkie są zapisane małymi literami.
Benjol
1
@Benjol, nie wszystkie z nich, ale na pewno wiele z nich, takich jak sp_who. Dobrze jest przynajmniej spróbować być konsekwentnym w tym samym sproc, czego Microsoft nie ma w wielu „przypadkach”. Pun, przeznaczone. LOL
Gordon Bell,

Odpowiedzi:

107

To tylko kwestia stylu, prawdopodobnie pochodzącego z czasów, gdy redaktorzy nie kolorowali kodu.

Kiedyś wolałem wszystkie wielkie litery, ale teraz skłaniam się ku mniejszym.

Mitch Wheat
źródło
6
+1 Chyba nie tylko ja stosowałem wszystkie dolne słowa kluczowe.
dance2die
2
Wychodziłbym z założenia, że ​​to powrót do czasów, kiedy redaktorzy nie kolorowali kodu.
Benjol
10
Jestem prawie pewien, że sięga czasów, kiedy wiele maszyn nie obsługiwało małych liter.
Nate CK
1
Myślę, że to sięga do czasów sprzed kolorowych monitorów;)
walrii
150

OSOBIŚCIE NIE LUBIĘ, ŻE MÓJ SQL na mnie krzyczy. PRZYPOMINA MI BASIC LUB COBOL.

Dlatego wolę małe litery w języku T-SQL z nazwami obiektów bazy danych MixedCase.

Jest dużo łatwiejszy do odczytania, a literały i komentarze wyróżniają się.

Gordon Bell
źródło
8
To tak bardzo kwestia gustu. Z mojego doświadczenia wynika, że ​​ilość wrzasków nie jest zbyt duża - wolę słowa kluczowe pisane dużymi literami, ponieważ jest dużo łatwiejszy do odczytania, a dosłowne i komentarze wyróżniają się.
Jonathan Leffler,
93
+1 za „NIE LUBIĘ MOJEGO SQL YELLING NA MNIE”
dance2die
8
Nie lubię krzyczeć na mnie, ale to nie prowadzi do pytania, czy wielkie litery są dobrym pomysłem w SQL.
bignose
85

SQL JEST STARY. KRZYCZY GÓRNA LITERA. WYGLĄDA DZIWNIE I MOŻE BYĆ Brzydki.

Chociaż prawdopodobnie jest to prawda, żadna z nich nie dotyczy szczególnych powodów dla języka SQL, dla których słowa kluczowe składające się z dużych liter są dobrą konwencją.

W przeciwieństwie do wielu nowszych języków, SQL ma dużą liczbę słów kluczowych i polega na zdolności czytelnika do odróżnienia słów kluczowych od identyfikatorów w celu mentalnego przeanalizowania składni.

Zatem bezpośrednia odpowiedź na twoje pytanie jest bardziej odpowiedzią na pytanie „dlaczego czytelnik kodu SQL korzysta tak bardzo ze słów kluczowych pisanych wielkimi literami, skoro nie jest to tak prawdziwe w przypadku większości współczesnych języków?”:

  • Poleganie na zachowaniu słów kluczowych w głowie jest rozsądne w przypadku wielu współczesnych języków, ale nierozsądne w przypadku SQL ; zawiera zbyt wiele słów kluczowych i zbyt wiele wariantów.

  • Poleganie na znakach interpunkcyjnych jest rozsądne w przypadku większości współczesnych języków, ale nierozsądne w przypadku języka SQL ; ma ich za mało, zamiast tego zależy od dokładnej kolejności słów kluczowych, aby wskazać składnię.

  • Poleganie na automatycznych podświetlaczach do rozróżniania słów kluczowych jest rozsądne we współczesnych językach w zwykłych przypadkach, ale ignoruje rzeczywistość tego, co podświetlacze mogą osiągnąć w SQL . Większość z nich nie obejmuje wszystkich słów kluczowych ze wszystkich wariantów SQL, a mimo to SQL jest często i rutynowo czytany w kontekstach, w których zakreślacz nie pomoże.

Oto niektóre z powodów, specyficznych dla języka SQL, dla których czytelnik kodu SQL najlepiej jest obsłużyć poprzez ujednolicenie słów kluczowych na duże litery i używanie tylko wielkich liter (tj. Małych lub mieszanych) dla identyfikatorów.

Podświetlanie może czasami pomóc. Ale tylko wtedy, gdy zakreślacz wie, że masz SQL; i bardzo często mamy SQL w kontekście, w którym edytor / program formatujący nie może wiedzieć, że ma do czynienia z SQL. Przykłady obejmują zapytania w wierszu, dokumentację programisty i ciągi tekstowe w kodzie innego języka. To samo nie dotyczy języków takich jak Python czy C ++; tak, ich kod czasami pojawia się w tych miejscach, ale nie jest to rutynowo wykonywane tak, jak w przypadku kodu SQL.

Ponadto czytelnik będzie często używał zakreślacza, który zna tylko podzbiór słów kluczowych używanych w konkretnej implementacji SQL. Wiele mniej popularnych słów kluczowych nie zostanie wyróżnionych, z wyjątkiem takiego, który dokładnie zna Twój wariant SQL. Tak więc czytelnik, nawet jeśli używa zakreślacza, nadal potrzebuje bardziej bezpośredniego sposobu rozróżniania słów kluczowych w każdej średnio złożonej instrukcji SQL.

W związku z tym czytelnik często - a autor nie może wiedzieć z wyprzedzeniem, kiedy to nastąpi - będzie potrzebował pomocy z treści samej instrukcji SQL, aby wiedzieć, co jest zamierzone przez autora jako słowo kluczowe, a co ma służyć jako identyfikator. Tak więc sama treść SQL musi rozróżniać słowa kluczowe dla czytelnika , a użycie słów kluczowych pisanych wielkimi literami jest konwencjonalnym i użytecznym sposobem na zrobienie tego.

duży nos
źródło
Uważam, że ścisły powód tego pytania jest całkiem dobry. Twoja odpowiedź jest dobrze wyjaśniona, ale nadal wygląda na nieco opartą na opiniach. Nie wydaje mi się, aby SQL miał tak wiele słów kluczowych. W każdym razie, jak często widzisz innych po 50 słowach kluczowych, które są częstsze? Czy nadal ma znaczenie, aby wyświetlać je wielkimi literami? Ponieważ są rzadkie, i tak przyciągają uwagę, prawda? Oczywiście te cholerne „niezarezerwowane słowa kluczowe”, takie jak sql-server, throwzasługują na specjalne traktowanie, ale wielkie litery to tylko jedna z wielu opcji.
Frédéric
1
@ Frédéric, wydaje się, że argumentujesz, że czytelnik nie musi oznaczać mniej znanych słów kluczowych jako słów kluczowych. Nie, takie słowa nie przyciągają uwagi właśnie dlatego, że czytelnik nie może wiedzieć, że to są słowa kluczowe; dlatego należy je rozróżniać jako słowa kluczowe, jak każde inne.
bignose
Może po prostu jestem zbyt nieświadomy SQL, chociaż moje wieloletnie programowanie w języku SQL, ale do tej pory uważam, że zawsze prawie natychmiast dostrzegałem słowa kluczowe, których nie znałem, ponieważ skutkowały one niezwykłą konstrukcją SQL, przynajmniej dla kogoś, kto nie znam ich.
Frédéric
33

Przykłady Gordona Bella nie są dokładnie poprawne; ogólnie podświetlane są tylko słowa kluczowe, a nie całe zapytanie. Jego drugi przykład wyglądałby tak:

SELECT name, id, xtype, uid, info, status, 
base_schema_ver, replinfo, parent_obj, crdate, 
ftcatid, schema_ver, stats_schema_ver, type, 
userstat, sysstat, indexdel, refdate, version, 
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

Jest to o wiele łatwiejsze do odczytania, ponieważ słowa kluczowe bardziej się wyróżniają. Nawet przy podświetlaniu składni uważam, że przykład bez wielkiej litery jest znacznie trudniejszy do odczytania.

W mojej firmie posuwamy się nieco dalej w zakresie naszego formatowania SQL.

SELECT      name, id, xtype, uid, info, status, 
            base_schema_ver, replinfo, parent_obj, crdate, 
            ftcatid, schema_ver, stats_schema_ver, type, 
            userstat, sysstat, indexdel, refdate, version, 
            deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
LEFT JOIN systhingies ON
    sysobjects.col1=systhingies.col2
WHERE category = 0
    AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1
davidtbernal
źródło
1
Tak, to też mi się podoba.
David The Man
6
Problem w tym, że ... Jeśli użyjesz wielkich liter podczas uruchamiania poleceń ad-hoc w monicie, zawsze będziesz 1/2 tak szybko, jak ktoś, kto ich nie używa, jeśli kiedykolwiek będziesz musiał uruchamiać polecenia ad-hoc w środowisku produkcyjnym ma znaczenie. Więc piszę to wszystko małymi literami, a następnie „upiększam” to przed zameldowaniem, gdy ktoś narzeka, że ​​nie może go przeczytać, ponieważ nie wie, jak uruchomić podświetlanie składni. I nie wiem jak wy, ale 3 razy w roku muszę uruchamiać polecenia ad-hoc w tempie produkcji, naprawdę ma to znaczenie, więc 50% dni roboczych, w których ćwiczyłem pisanie zapytań testowych małymi literami, naprawdę się opłaca.
7
A w bazie danych mojej firmy (utworzonej gdzieś w latach 90-tych) wszystkie nazwy tabel, kolumny, indeksy, procedury składowane itp. Są pisane wielkimi literami, dlatego używamy słów kluczowych SQL pisanych małymi literami. ;)
Andreas
1
Wow 1/2 tak szybko. Nie sądzę!
Iharob Al Asimi
33

BYŁ CZAS, W KTÓRYM WIĘKSZOŚĆ LUDZI NIE MIAŁ MOŻLIWOŚCI KODOWANIA CZEGOKOLWIEK WIĘKSZYMI LITERAMI, PONIEWAŻ NIE WYKONANO JESZCZE ODPOWIEDNIE KODOWANIE (ASCII). DOSTĘPNYCH BYŁO TYLKO SZEŚĆ BITÓW . JEŚLI SQL JESZCZE JESZCZE JESZCZE NIE BYŁA POCZĄTKOWĄ PRAKTYKĄ W PROGRAMOWANIU, WIELKIE LITERY NIE BYŁY.

NALEŻY PAMIĘTAĆ, ŻE NIEKTÓRE LUDZIE TWIERDZĄ, ŻE BAZA DANYCH BĘDZIE POCZUĆ PILNOŚĆ I SZYBCIEJ WYDAJE TWOJE PYTANIA.

Lukas Eder
źródło
Więc dzisiaj nie jest to dobry powód.
bignose
1
@BIGNOSE: NIE, ABSOLUTNIE NIE!
Lukas Eder
1
Myślę, że to najlepsza odpowiedź. Niestety, po prostu nienawidzę małych liter w słowach kluczowych SQL i nie mogę znaleźć sposobu, aby polubić małe litery. Czy jestem szalony?
Iharob Al Asimi
@IharobAlAsimi YES YOU A CRAZY. DLACZEGO PISZESZ ANGIELSKI W DOLNEJ LITERZE, ALE MOT STRUKTURYZOWANY ANGIELSKI?
Lukas Eder
24

Mniej niż 10% liter w czytanym tekście to duże litery. Stąd nasze mózgi chętniej rozpoznają małe litery niż duże. Badania wykazały, że czytanie tekstu pisanego wielkimi literami zajmuje więcej czasu. Oto tylko jeden przykład:

http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals

Myślę, że powyższy przykład podkreśla, że ​​nawet gdy mówisz o jednym lub dwóch słowach, robi to różnicę.

AaronLS
źródło
5
Nie mówimy o czytaniu powieści w całości; mówimy o kilku słowach kluczowych, które stanowią tylko część tekstu.
Casey,
6
Nie rozumiesz. Nie chodzi o to, ile słów czytamy, ale o to, do czego nasz mózg został wyszkolony w szybkim tempie. Na przykład znak drogowy z pewnością nie jest powieścią, ale doszli do tego samego wniosku. Kiedy uczymy się czytać, zaczynamy czytać każdą literę, ale w końcu nasz mózg zaczyna rozpoznawać słowo jako zbiór wzorców. Lepiej, jeśli te wzorce są spójne. Pamiętaj, że duże litery są często innym wzorem niż małe, a nie tylko większą wersją.
AaronLS
1
Ale słów kluczowych jest bardzo mało i pojawiają się one w kółko; Rozpoznawanie powinno zatem być równie szybkie dla każdego, kto używa SQL przez jakikolwiek czas.
Casey,
3
To prawda, na pewno nie jest to coś twardego i szybkiego. Ale jest tylko kilka bardzo popularnych słów kluczowych. Istnieje duży zestaw, których nie ma i często ludzie rozszerzają tę praktykę wielkich liter na rzeczy, które są funkcjami wbudowanymi, ale niekoniecznie są słowami kluczowymi języka składniowego. W praktyce wciąż przekraczam garść słów kluczowych, takich jak SELECT / WHERE / GROUP BY, które wskazują początek głównej sekcji zapytania. Ale wszystkie inne słowa kluczowe, takie jak wbudowane funkcje takie jak cast, rank, mam małe litery.
AaronLS
19

To dlatego, że SQL jest tak starym językiem ( 1974 ), że kiedy został wymyślony, większość klawiatur nie miała małych liter! Dokumentacja językowa po prostu odzwierciedlała technologię tamtych czasów.

Badania dowiodły, że WIELKIE LITERY są trudniejsze do odczytania, do tego stopnia, że ​​Federalna Administracja Autostrad USA nakazała stosowanie znaków o różnej wielkości w swoim podręczniku dotyczącym jednolitych urządzeń kontroli ruchu, który stanowi:

Litery nazw miejsc, ulic i autostrad na konwencjonalnych drogowskazach drogowych powinny być kombinacją małych liter z początkowymi dużymi literami.

New York Post opublikował również:

Badania wykazały, że trudniej jest odczytać napisy z wielkimi literami, a dodatkowe milisekundy spędzone na gapieniu się z dala od drogi zwiększają prawdopodobieństwo wypadków, szczególnie wśród starszych kierowców.

Nie ma dobrego powodu, aby używać wielkich liter i są dobre powody, aby tego nie robić.

Osobiście nie cierpię używania wielkich liter w słowach kluczowych SQL. W dzisiejszych czasach jest mi trudniej czytać i absurdalnie.

Język SQL jest definiowany jako niewrażliwy na wielkość liter. Zdejmij palec z klawisza Shift!

Czeski
źródło
3
Myślę, że rozpowszechnienie dobrych powodów przedstawionych w innych odpowiedziach przemawia przeciwko Twojemu stwierdzeniu „nie ma dobrego powodu, aby używać wielkich liter”.
bignose
7
@bignose Och, są powody ... Po prostu nie sądzę, że są dobre. Z mojego doświadczenia wynika, że ​​im młodszy programista SQL, tym większe prawdopodobieństwo, że będą używać wielkich liter. I odwrotnie, nigdy nie spotkałem kompetentnego programisty SQL używającego wielkich liter.
Bohemian
3
Całkowicie się zgadzam. Powszechność innych „odpowiedzi” nie czyni ich poprawnymi, po prostu czyni je dominującymi. WSZYSTKIE GÓRNE LITERY TO HANGOVER, KTÓRYCH KOMPUTERY NIE MIAŁY OBUDOWY NA KLAWIATURACH ANI W SWOICH REPREZENTACJACH ZNAKÓW DZISIAJ TO PO PROSTU GŁUPA.
Charles Bretana
Tak, i zużywanie klawisza CAPS LOCK lub skurcz palców niepotrzebnie przytrzymując klawisz Shift.
Gordon Bell,
9
Czuję tu okrężne rozumowanie. Jeśli powodem jest przedstawiony za dyskryminujące słowa kluczowe przypadku należy odrzucić go jako a nie dobrego powodu. Jeśli powodem jest prezentowany przez koder SQL, ale nie zgadza się ze swojej pozycji, należy odrzucić je jako nie będąc właściwy SQL koder. Myślę, że na tej podstawie możemy odrzucić ten argument jako nieważny.
bignose
8

Wielkie litery mogą zapewnić poprawę widoczności słów kluczowych, ale można to skompensować podświetleniem kodu i wcięciami.
Używamy małych liter, ponieważ edytor zapytań i inne narzędzia robią cuda podczas edycji kodu t-sql i nie widzimy potrzeby torturowania małego palca.

Ovidiu Pacurar
źródło
2
Czy edytor zapytań i t-sql to jedyne miejsca, w których ktoś będzie czytać Twój kod SQL? Skąd wiesz?
bignose
8

Małpa widzisz, małpa robi dla mnie. Dopasowywanie wzorców - jeśli zrobię to tak, jak widziałem, struktura klauzul układa się mentalnie łatwiej.

dkretz
źródło
7

Wielkie litery są mniej czytelne. Kontury wszystkich słów mają kształt pudełek; nie ma zstępujących ani wznoszących się. Małe litery FTW!

Lance Fisher
źródło
3
Podany powód potwierdza pozycję, w której wielkie litery pomagają odróżnić słowa kluczowe od reszty.
bignose
5
@bignose Jeśli SQL czyta jak język ludzki, po co nam wielkie litery? W języku ludzkim nie potrzebujemy wielkich liter ani przyimków. Wyobraź sobie, że KAŻDE zdanie wyglądało TAK. Uważam, że jest to mniej czytelne niż zwykłe pisanie. Wyrazy zapisane wielkimi literami w tych dwóch zdaniach powodują, że mój mózg zatrzymuje się i wypowiada je wolniej niż reszta zdania, spowalniając moje czytanie i sprawiając, że przepływ jest mniej naturalny.
Chris Middleton,
1
Język ludzki bardzo wybacza wieloznaczność składni. Języki komputerowe nie są, dlatego te niejasności należy zminimalizować. Składnia SQL nie pomaga w tym, więc my, ludzie, musimy korzystać z dostępnych narzędzi; Składnia SQL nie ma wiele, dlatego rozwinęliśmy konwencję używania słów kluczowych z wielkimi literami.
bignose
5

Uważam, że jest bardziej czytelny. To samo dotyczy nowej linii na początku każdej klauzuli i wcięć między klauzulami.

Mark Bostleman
źródło
2

Wypróbuj produkt do formatowania (używam SQL Prompt / SQL Refactor z Red Gate). Możesz ustawić, jak chcesz, aby wielkie litery działały, a Twój kod zawsze będzie konsekwentnie sformatowany. Odpocznij i pozwól komputerowi wykonać pracę za Ciebie.

mruczeć
źródło
1
Ta rada ignoruje wiele kontekstów, w których czyta się SQL. Czytanie kodu już napisanego przez kogoś innego jest całkowicie niepraktyczne; jeśli takie narzędzie jest potrzebne tylko do uczynienia źle sformatowanego SQL czytelnym, jest to argument przemawiający za konwencją taką, jak ta, do której odnosi się to pytanie.
bignose
ale to podejście jest dobre, jeśli chcesz, aby standardy w całej organizacji. Jeśli chcesz standardów, opinia nie ma znaczenia
Trubs
2

Jednym z powodów, dla których nadal używasz wielkich liter, jest to, że gdy Ty (lub ktoś inny) przeglądasz kod w czymś takim jak notatnik, ułatwia to czytanie. tzn. można łatwo odróżnić "słowa kluczowe" od nazw tabel, SP, UDF itp

CPU_BUSY
źródło
1

Inne niż zgodność ze względu na zgodność, nie. Chociaż jest to bardzo subiektywny temat, wolę używać mieszanych wielkości liter dla wszystkich SQL. SQL jest znacznie łatwiejszy do odczytania i nic nie jest stracone w nowoczesnych IDE, w których słowa kluczowe i tak są kodowane kolorami.

Charles Bretana
źródło
Ponieważ wiele innych odpowiedzi przedstawiło powody, nie sądzę, aby twoja odpowiedź była poprawna: istnieją powody „inne niż konformizm dla konformizmu”.
bignose
... więc czym one są? Chociaż zawsze jestem otwarty na nowe informacje, szczerze mówiąc, nigdy o nich nie wiedziałem.
Charles Bretana
Podałem już wiele powodów , więc teraz jesteś świadomy.
bignose
2
żaden z nich nie jest uzasadnionym powodem, są to osobiste preferencje. Nie krępuj się postępować zgodnie z własnymi osobistymi preferencjami, ale nie określaj preferencji jako reguły lub najlepszej praktyki.
Charles Bretana
1

Funkcja Intellisense / autouzupełnianie w programie Microsoft SQL Server Management Studio umożliwia stosowanie wielkich lub małych liter w słowach zastrzeżonych, ale wywołania funkcji z wielkich liter, takie jak MAX (), SUM ().

Mimo to parser nadal umożliwia przetwarzanie małych liter max () i sum ().

Oznacza to ambiwalencję w odniesieniu do charakteru egzekucji, a zatem jest to po prostu kwestia osobistych preferencji.

Rachunek
źródło
4
Tak, w SSMS "Opcje -> Edytor tekstu -> Transact-SQL -> Intellisense" możesz ustawić domyślne na „Małe litery”, jeśli wolisz.
Gordon Bell
0

Nie podoba mi się wszystko, co jest napisane wielkimi literami (i jeszcze bardziej nienawidzę ich wpisywać), ale nie mogłem się przekonać, żebym wystąpił przeciwko społeczności. Jak zwykle Vim i powiązane z nim pakiety są rozwiązaniem wielu problemów:

http://www.vim.org/scripts/script.php?script_id=305

Po prostu wpisz jak zwykle, a słowa kluczowe będą automatycznie włączane do wielkich liter podczas wpisywania. Nie użyłem wszystkich niejasnych zaklęć SQL, ale jeszcze mnie to nie zawiodło.

Ferdinand van Wyk
źródło
-2

Większość kodu MySQL wywołuję z poziomu PHP, a całą edycję PHP wykonuję w vimie (lub w tym przypadku w VIM ;-). Teraz jestem pewien, że istnieją wtyczki do podświetlania kodu mySQL w PHP, ale nie znalazłem go i nie mam czasu, aby go szukać. Dlatego wolę mieć wszystko na allcapsach. Znajduję to:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
CREATE TABLE IF NOT EXISTS HISTORY
(
   ID INT NOT NULL AUTO_INCREMENT,
   INSERTDATE TIMESTAMP DEFAULT NOW(),
   ALTERDATE TIMESTAMP(8) DEFAULT NOW(),
   DELETEDATE TIMESTAMP(8),
   ALTERCOUNT INT DEFAULT 0,
   SELECTCOUNT INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB
";

mysqlQuery( $query, $con );

Pomaga mi znacznie lepiej odróżnić PHP od SQL:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
create table if not exists history
(
   id int not null auto_increment,
   insertdate timestamp default now(),
   alterdate timestamp(8) default now(),
   deletedate timestamp(8),
   altercount int default 0,
   selectcount int default 0,

   primary key(id),
)engine=InnoDB
";

mysqlQuery( $query, $con );

Poza tym z jakiegoś powodu nienawidzę mieszać nasadek z wielbłądem, jak na przykład:

CREATE TABLE IF NOT EXISTS history
(
   ID INT NOT NULL AUTO_INCREMENT,
   insertDate TIMESTAMP DEFAULT NOW(),
   alterDate TIMESTAMP(8) DEFAULT NOW(),
   deleteDate TIMESTAMP(8),
   alterCount INT DEFAULT 0,
   selectCount INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB

To IDmnie irytuje. Czy zamiast tego powinno być id? czy iD?

rzygać
źródło
3
Nie, nie, nie, camelCase dotyczy nazw zmiennych, a nie nazw kolumn. Użyj właściwego przypadku dla nazw kolumn ... InsertDate, AlterDate, ...
Gordon Bell
1
Standard SQL wymaga od implementacji ignorowania wielkości liter w identyfikatorach (składa je do wielkich liter). Twój kod nie powinien więc zależeć od różnic wielkości liter w identyfikatorach, a konwencjonalnym sposobem jest tworzenie identyfikatorów all_lower_case.
bignose
3
@bignose nie jestem wielkim fanem podkreślenia, gdyż zmniejsza WPM
PUK