Różnica uważana za nieistotną.
Niemniej jednak należy odróżnić natywne przygotowane oświadczenia z ogólnej idei przygotowanego zestawienia.
To pierwsze to po prostu forma uruchamiania zapytań obsługiwana przez większość DBMS, wyjaśniona tutaj
. Jego użycie może być kwestionowane.
To ostatnie to ogólna idea zastępowania rzeczywistych danych symbolem zastępczym, co oznacza dalsze przetwarzanie podstawionych danych. Jest szeroko stosowany w programowaniu, dobrze znana printf() funkcja jest przykładem. I to drugie podejście musi być ZAWSZE używane do uruchamiania zapytania w bazie danych , bez względu na to, czy jest poparte natywnymi instrukcjami przygotowanymi, czy nie. Ponieważ:
- przygotowane oświadczenie sprawia, że prawidłowe formatowanie (lub obsługa) nieuniknione .
- przygotowana instrukcja prawidłowo formatuje (lub obsługuje) w jedynym właściwym miejscu - tuż przed wykonaniem zapytania, a nie gdzie indziej, więc nasze bezpieczeństwo nie będzie polegać na tak niewiarygodnych źródłach jak
- niektóre „magiczne” funkcje PHP, które raczej psują dane niż czynią je bezpiecznymi.
- dobrej woli jednego (lub kilku) programistów, którzy mogą zdecydować się na formatowanie (lub nieformatowanie) naszej zmiennej gdzieś w przepływie programu. To bardzo ważny punkt.
- przygotowane oświadczenie ma wpływ na samą wartość, która jest wprowadzana do zapytania, ale nie na zmienną źródłową, która pozostaje nienaruszona i może być użyta w dalszym kodzie (do wysłania e-mailem lub pokazana na ekranie).
- przygotowana instrukcja może znacznie skrócić kod aplikacji, wykonując całe formatowanie w tle (*tylko jeśli pozwala na to sterownik).
Tak więc, nawet jeśli uważasz, że nie korzystasz z natywnie przygotowanych instrukcji (co jest całkiem w porządku), zawsze musisz tworzyć zapytania za pomocą symboli zastępczych zamiast rzeczywistych danych. W tym celu możesz użyć PDO , który działa dokładnie tak, jak opisano powyżej - domyślnie po prostu emuluje przygotowania , oznacza zwykłe zapytanie SQL tworzone z przygotowanych zapytań i danych, a następnie uruchamiane w bazie danych.
Jednak PDO nie obsługuje wielu ważnych typów danych, takich jak identyfikator lub tablica - w związku z tym nie można zawsze używać symboli zastępczych, a tym samym wstrzyknięcie jest całkiem możliwe. Na szczęście safeMysql zawiera symbole zastępcze dla każdego typu danych i umożliwia bezpieczne uruchamianie zapytań.
