Korzystanie z odwrotnych apostrofów wokół nazw pól

Po przeczytaniu kilku odpowiedzi i komentarzy do niektórych pytań SQL tutaj, a także usłyszeniu, że mój przyjaciel pracuje w miejscu, w którym obowiązuje polityka, która go zakazuje, zastanawiam się, czy jest coś złego w używaniu odwrotnych apostrofów wokół nazw pól w MySQL .

To jest:

SELECT `id`, `name`, `anotherfield` ...
-- vs --
SELECT id, name, anotherfield ...

Korzystanie z lewych apostrofów pozwala na używanie alternatywnych znaków. Przy pisaniu zapytań nie jest to taki problem, ale jeśli przyjmie się, że można po prostu używać odwrotnych apostrofów, zakładam, że pozwala to uciec z absurdalnymi rzeczami, takimi jak

SELECT `id`, `my name`, `another field` , `field,with,comma` 

Co oczywiście generuje źle nazwane tabele.

Jeśli jesteś tylko zwięzły, nie widzę z tym problemu, zauważysz, że uruchomisz zapytanie jako takie

EXPLAIN EXTENDED Select foo,bar,baz 

Wygenerowane ostrzeżenie, które powróci, będzie zawierało znaczniki wsteczne i w pełni kwalifikowane nazwy tabel. Więc jeśli korzystasz z funkcji generowania zapytań i automatycznego ponownego pisania zapytań, lewe apostrofy sprawią, że wszystko, co analizuje kod, będzie mniej zagmatwane.

Myślę jednak, że zamiast narzucać możliwość używania znaków odwrotnych, powinny one mieć standard nazw. Rozwiązuje bardziej „rzeczywiste” problemy.

Jedynym problemem związanym z odwrotnymi znakami jest to, że nie są one zgodne z ANSI-SQL, np. Nie działają w SQL Server.

Jeśli istnieje szansa, że ​​będziesz musiał przenieść swój kod SQL do innej bazy danych, użyj podwójnych cudzysłowów.

Uważam, że używanie ich przez cały czas, gdy mamy do czynienia z nazwami pól, ma sens.

• Po pierwsze, kiedy już wpadniesz w nałóg, nie zaszkodzi samo naciśnięcie klawisza backtick.
• Po drugie, dla mnie łatwiej jest zobaczyć, jakie dokładnie są pola w zapytaniu i jakie są słowa kluczowe lub metody.
• Wreszcie, pozwala na użycie dowolnej nazwy pola podczas projektowania tabeli. Czasami sensowne jest nazwanie pola „kluczem”, „porządkiem” lub „wartościami” ... z których wszystkie wymagają znaków odwrotnych podczas odwoływania się do nich.

Backticks nie są częścią standardowego ANSI SQL. Z podręcznika mysql :

Jeśli tryb ANSI_QUOTES SQL jest włączony, dozwolone jest również cytowanie identyfikatorów w cudzysłowach

Więc jeśli użyjesz odwrotnych znaków, a następnie zdecydujesz się odejść od MySQL, masz problem (chociaż prawdopodobnie masz też dużo większe problemy)

Nie ma nic złego, jeśli nadal używasz MYSQL, z wyjątkiem może wizualnej niejasności zapytań. Ale pozwalają na użycie zastrzeżonych słów kluczowych lub osadzonych spacji jako nazw tabel i kolumn. W przypadku większości silników baz danych jest to nie-nie, które uniemożliwi późniejszą migrację.

Jeśli chodzi o łatwość czytania, wiele osób używa wielkich liter w słowach kluczowych SQL, np.

SELECT some_fied, some_other_field FROM whatever WHERE id IS NULL;

Jeśli o mnie chodzi, zawsze należy używać grawitacji. Ale jest kilka powodów, dla których zespół może chcieć ich nie używać.

Zalety:

• Używając ich, nie ma zastrzeżonych słów ani zabronionych znaków.
• W niektórych przypadkach otrzymujesz bardziej opisowe komunikaty o błędach.
• Jeśli unikasz złych praktyk, nie przejmujesz się, ale ... tak naprawdę, czasami są one dobrym sposobem na uniknięcie wstrzyknięć SQL.

Niedogodności:

• Nie są standardowe i zwykle nie są przenośne. Jednakże, o ile nie używasz znaku wstecznego jako części identyfikatora (co jest najgorszą praktyką, jaką mogę sobie wyobrazić), możesz przenieść zapytanie, automatycznie usuwając lewe apostrofy.
• Jeśli niektóre zapytania pochodzą z programu Access, mogą cytować nazwy tabel za pomocą „(i być może nie możesz usunąć wszystkich„ na ślepo ”). Dozwolone są jednak mieszanki apostrofów i cudzysłowów.
• Niektóre głupie programy lub funkcje filtrują zapytania i mają problemy z grawitacjami. Są one jednak częścią ASCII, więc oznacza to, że oprogramowanie / funkcja jest bardzo złe.

O wiele łatwiej jest przeszukać bazę kodu w celu znalezienia czegoś w odwrotnych znakach. Powiedzmy, że masz tabelę o nazwie event. grep -r "event" *może zwrócić setki wyników. grep -r "\`event\`" *zwróci wszystko, co prawdopodobnie odnosi się do Twojej bazy danych.

Cóż, o ile wiem, głównym celem używania grawisów jest to, że możesz używać nazw, które pokrywają się z zastrzeżonymi słowami kluczowymi. Tak więc, jeśli nazwa nie koliduje z zastrzeżonym słowem kluczowym, nie widzę powodu, aby używać odwrotnych apostrofów. Ale to też nie powód, by ich zakazać.

Prosta rzecz dotycząca znaku wstecznego `` jest używana do oznaczenia identyfikatora, takiego jak nazwa_bazy_danych, nazwa_tabeli itp., I pojedynczego cudzysłowu '' , podwójnego cudzysłowu "" dla literałów łańcuchowych, natomiast "" użyj do wypisania wartości bez zmian i '' wydrukuj zmienną wartości trzymaj lub w innym przypadku wydrukuj jego tekst.

i.e 1.-> use `model`;   
    here `model` is database name not conflict with reserve keyword 'model'
2- $age = 27;
insert into `tbl_people`(`name`,`age`,`address`) values ('Ashoka','$age',"Delhi");

here i used both quote for all type of requirement. If anything not clear let me know..

jeśli używasz niektórych nazw pól jako domyślnych wartości mysql lub mssql, na przykład „status”, musisz użyć odwrotnych apostrofów („wybierz statusz nazwa_tabeli” lub „wybierz id z nazwa_tabeli, gdzie status= 1”). ponieważ mysql zwraca błędy lub nie działa na zapytanie.

Głównym zastosowaniem backticks (`) w SQL jest użycie ich w sytuacjach, w których zamierzasz wywołać je ponownie w nadchodzących klauzulach. W każdym innym przypadku zaleca się używanie cudzysłowów („”).

Na przykład

SELECT CONCAT(Name, ' in ', city, ', ', statecode) AS `Publisher and Location`,
    COUNT(ISBN) AS "# Books",
    MAX(LENGTH(title)) AS "Longest Title",
    MIN(LENGTH(title)) AS "Shortest Title"
FROM Publisher JOIN Book
ON Publisher.PublisherID = Book.PublisherID WHERE INSTR(name, 'read')>0
GROUP BY `Publisher and Location`
HAVING COUNT(ISBN) > 1;

W powyższym stwierdzeniu widzisz, jak Publisher and Locationjest używany ponownie w GROUP BYklauzuli.

Zamiast używać

GROUP BY Nazwa, miasto, kod stanu

Właśnie użyłem

GRUPUJ WEDŁUG Publisher and Location

Dopiero w takich sytuacjach warto używać lewych cudzysłowów. We wszystkich innych przypadkach zalecane jest używanie podwójnych cudzysłowów.