Dlaczego ktoś miałby używać WHERE 1=1 i w klauzuli SQL?

Wystarczy dodać przykładowy kod do odpowiedzi Grega:

dim sqlstmt as new StringBuilder
sqlstmt.add("SELECT * FROM Products")
sqlstmt.add(" WHERE 1=1") 

''// From now on you don't have to worry if you must 
''// append AND or WHERE because you know the WHERE is there
If ProductCategoryID <> 0 then
  sqlstmt.AppendFormat(" AND ProductCategoryID = {0}", trim(ProductCategoryID))
end if
If MinimunPrice > 0 then
  sqlstmt.AppendFormat(" AND Price >= {0}", trim(MinimunPrice))
end if

Widziałem go używany, gdy liczba warunków może być zmienna.

Warunki można łączyć za pomocą łańcucha "i". Następnie, zamiast liczyć liczbę warunków, które przekazujesz, umieszczasz "WHERE 1=1" na końcu instrukcji stock SQL i rzucasz na skonkatenowane warunki.

Zasadniczo oszczędza to konieczności wykonania testu dla warunków, a następnie dodania ciągu "gdzie" przed nimi.

Wygląda na leniwy sposób, aby zawsze wiedzieć, że Twoja klauzula WHERE jest już zdefiniowana i pozwala ci na dodawanie warunków bez konieczności sprawdzania, czy jest to pierwsza.

Pośrednio istotne: gdy stosuje się 1=2:

CREATE TABLE New_table_name 
as 
select * 
FROM Old_table_name 
WHERE 1 = 2;

Spowoduje utworzenie nowej tabeli z tym samym schematem co stara tabela. (Bardzo przydatne, jeśli chcesz załadować niektóre dane do porównania)

1 = 1 wyrażenie jest powszechnie używane w generowanym kodzie sql. To wyrażenie może uprościć generowanie kodu sql, zmniejszając liczbę instrukcji warunkowych.

Widziałem takie rzeczy używane w raportach Birta. Zapytanie przekazywane do środowiska uruchomieniowego BIRT ma postać:

select a,b,c from t where a = ?

I'?'jest zastępowane w czasie wykonywania przez rzeczywistą wartość parametru wybraną z listy rozwijanej. Wybór w rozwijanym menu jest podany przez:

select distinct a from t
union all
select '*' from sysibm.sysdummy1

, aby otrzymać wszystkie możliwe wartości plus " *". Jeśli użytkownik wybierze "* " z listy rozwijanej (co oznacza, że należy wybrać wszystkie wartości a), zapytanie musi zostać zmodyfikowane (przez Javascript) przed bycie uciekającym.

Od "?"jest parametrem pozycyjnym i musi tam pozostać, aby inne rzeczy działały, Javascript modyfikuje zapytanie na:

select a,b,c from t where ((a = ?) or (1==1))

To zasadniczo usuwa efekt klauzuli where, pozostawiając parametr pozycyjny na swoim miejscu.

Widziałem również przypadek AND używany przez leniwych programistów podczas dynamicznego tworzenia zapytania SQL.

Powiedz, że musisz dynamicznie utworzyć zapytanie, które zaczyna się od select * from t i sprawdza:

• the mam na imię Bob; i
• pensja wynosi > $20,000

Niektórzy ludzie dodaliby pierwsze z WHERE I kolejne z i tak:

select * from t where name = 'Bob' and salary > 20000

Leniwi Programiści (a to niekoniecznie jest zła cecha ) nie rozróżnialiby dodanych warunków, zaczynaliby od select * from t where 1=1 i po prostu dodawali i klauzule.

select * from t where 1=1 and name = 'Bob' and salary > 20000

Znalazłem przydatny ten wzór, gdy testuję lub sprawdzam rzeczy w bazie danych, więc mogę bardzo szybko skomentować inne warunki:

CREATE VIEW vTest AS
SELECT FROM Table WHERE 1=1 
AND Table.Field=Value
AND Table.IsValid=true

Zamienia się w:

CREATE VIEW vTest AS
SELECT FROM Table WHERE 1=1 
--AND Table.Field=Value
--AND Table.IsValid=true

Gdzie 1=0, odbywa się to w celu sprawdzenia, czy tabela istnieje. Nie wiem dlaczego 1=1 jest używany.

Chociaż widzę, że 1=1 byłby przydatny dla generowanego SQL, technika, której używam w PHP, polega na utworzeniu tablicy klauzul, a następnie wykonaniu

implode (" AND ", $clauses);

W ten sposób unikamy problemu posiadania wiodącej lub ciągłej i. Oczywiście jest to przydatne tylko wtedy, gdy wiesz, że masz zamiar mieć co najmniej jedną klauzulę!

Oto ściśle powiązany przykład: użycie instrukcji SQL MERGE do aktualizacji celu przy użyciu wszystkich wartości z tabeli źródłowej, gdzie nie ma wspólnego atrybutu, na którym można się połączyć np.

MERGE INTO Circles
   USING 
      (
        SELECT pi
         FROM Constants
      ) AS SourceTable
   ON 1 = 1
WHEN MATCHED THEN 
  UPDATE
     SET circumference = 2 * SourceTable.pi * radius;

Dlaczego ktoś miałby używać WHERE 1=1 i <proper conditions>

Widziałem frameworki homespun robią takie rzeczy ( blush), ponieważ pozwala to na stosowanie leniwych praktyk parsowania zarówno do słów kluczowychWHERE, jak i AND Sql.

Na przykład (używam C# jako przykład tutaj), rozważ warunkowe parsowanie następujących predykatów w zapytaniu Sql string builder:

var sqlQuery = "SELECT * FROM FOOS WHERE 1 = 1"
if (shouldFilterForBars)
{
    sqlQuery = sqlQuery + " AND Bars > 3";
}
if (shouldFilterForBaz)
{
    sqlQuery = sqlQuery + " AND Baz < 12";
}

"korzyść" z WHERE 1 = 1 oznacza, że żaden specjalny kod nie jest potrzebne:

• dla I - czy należy zastosować zero, jeden lub oba predykaty (bary i Baz), które określiłyby, czy wymagana jest pierwsza AND. Ponieważ mamy już przynajmniej jeden predykat z 1 = 1, oznacza to, że AND jest zawsze w porządku.
• Dla żadnych predykatów - w przypadku, gdy istnieją predykaty zerowe, to WHERE musi zostać odrzucony. Ale znowu, możemy być leniwi, ponieważ znowu jesteśmy gwarancją co najmniej jednego orzeczenia.

To jest to oczywiście zły pomysł i zalecałby użycie ustalonej struktury dostępu do danych lub ORM do przetwarzania opcjonalnych i warunkowych predykatów w ten sposób.

Jeśli szukasz WHERE 1, zauważ, że WHERE 1 i WHERE 1=1 są identyczne. WHERE 1 jest używany rzadko, ponieważ niektóre systemy bazodanowe odrzucają go, ponieważ WHERE 1 nie jest tak naprawdę boolean.

Jest to przydatne w przypadku, gdy musisz użyć dynamicznego zapytania, w którym w klauzula musisz dołączyć kilka opcji filtrowania. Na przykład jeśli dodasz opcje 0 dla status jest nieaktywny, 1 dla aktywny. Na podstawie opcji, są tylko dwie dostępne opcje (0 i 1), ale jeśli chcesz wyświetlić wszystkie rekordy, jest to przydatne do włączenia w where close 1=1. Patrz poniżej przykład:

Declare @SearchValue    varchar(8) 
Declare @SQLQuery varchar(max) = '
Select [FirstName]
    ,[LastName]
    ,[MiddleName]
    ,[BirthDate]
,Case
    when [Status] = 0 then ''Inactive''
    when [Status] = 1 then ''Active''
end as [Status]'

Declare @SearchOption nvarchar(100)
If (@SearchValue = 'Active')
Begin
    Set @SearchOption = ' Where a.[Status] = 1'
End

If (@SearchValue = 'Inactive')
Begin
    Set @SearchOption = ' Where a.[Status] = 0'
End

If (@SearchValue = 'All')
Begin
    Set @SearchOption = ' Where 1=1'
End

Set @SQLQuery = @SQLQuery + @SearchOption

Exec(@SQLQuery);

Po przejrzeniu wszystkich odpowiedzi postanowiłem przeprowadzić eksperyment typu

SELECT
*
FROM MyTable

WHERE 1=1

Potem sprawdziłem innymi numerami

WHERE 2=2
WHERE 10=10
WHERE 99=99

Ect Po wykonaniu wszystkich kontroli, zapytanie Uruchom miasto jest taka sama. nawet bez klauzuli where. Nie jestem fanem składni

Robię to zwykle, gdy buduję dynamiczny SQL dla raportu, który ma wiele wartości rozwijanych, które użytkownik może wybrać. Ponieważ użytkownik może lub nie może wybrać wartości z każdego rozwijanego menu, trudno nam się domyślić, który warunek był pierwszą klauzulą where. Tak więc podajemy zapytanie where 1=1 na końcu i dodajemy po nim wszystkie klauzule where.

Coś jak

select column1, column2 from my table where 1=1 {name} {age};

Wtedy zbudowalibyśmy klauzulę where w ten sposób i przekazalibyśmy ją jako parametr wartość

string name_whereClause= ddlName.SelectedIndex > 0 ? "AND name ='"+ ddlName.SelectedValue+ "'" : "";

Ponieważ wybór klauzuli where nie jest nam znany w czasie wykonywania, więc pomaga nam to w znalezieniu, czy dodać 'AND' or 'WHERE'.

Pierwszy raz natknąłem się na to z ADO i klasyczną asp, odpowiedź jaką otrzymałem brzmiała: wydajność. if you do a straight

Select * from tablename

I przekaż to jako polecenie sql / tekst otrzymasz zauważalny wzrost wydajności z

Where 1=1

Dodał, to była widoczna różnica. coś związanego z zwracaniem nagłówków tabeli, gdy tylko spełniony jest pierwszy warunek, lub inne szaleństwo, w każdym razie, przyspieszyło to wszystko.

Używanie predykatu podobnego do 1=1 jest normalną podpowiedzią używaną czasami, aby wymusić na planie dostępu użycie lub nie użycie skanowania indeksu. Powodem, dla którego jest to używane, jest użycie wielozadaniowego połączonego zapytania z wieloma predykatami w klauzuli where, gdzie czasami nawet użycie wszystkich indeksów powoduje, że plan dostępu odczytuje każdą tabelę-Pełne skanowanie tabeli. Jest to tylko jedna z wielu podpowiedzi używanych przez DBAs, aby oszukać dbms, aby użyć bardziej wydajnej ścieżki. Tylko nie wrzucaj, potrzebujesz dba, aby przeanalizuj zapytanie, ponieważ nie zawsze działa.

Oto przykład użycia... jednak nie jestem zbyt zainteresowany szczegółami technicznymi, dlaczego powinienem lub nie używać 1 = 1. Piszę funkcję, używając pyodbc do pobierania niektórych danych z serwera SQL. Szukałem sposobu, aby wymusić wypełniacz po słowie kluczowym where w moim kodzie. To była naprawdę świetna sugestia:

if _where == '': _where = '1=1'
...
...
...
cur.execute(f'select {predicate} from {table_name} where {_where}')

Powodem jest to, że nie mogłem zaimplementować słowa kluczowego "where" razem wewnątrz zmiennej klauzuli _where. Więc myślę, że używając dowolnego warunku obojętnego, który ocenia na true przydałby się jako wypełniacz.

Uczynienie "where 1=1" standardem dla wszystkich zapytań sprawia również, że banalnie łatwo jest zweryfikować sql, zastępując go where 1 = 0, przydatnym, gdy masz partie poleceń/plików.

Ułatwia również znalezienie końca sekcji from / join dowolnego zapytania. Nawet zapytania z pod-zapytaniami, jeśli są prawidłowo wcięte.