Moją osobistą preferencją jest tworzenie ciągów znaków do zmiennych wiązania (VARCHAR2) i pozwalanie Oracle na konwersję ze znaku na własny format pamięci wewnętrznej. Dosyć łatwo (w C) jest uzyskanie wartości danych reprezentowanych jako ciągi zakończone znakiem NULL, w akceptowalnym formacie.
Więc zamiast pisać SQL w ten sposób:
SET MY_NUMBER_COL = :b1
, MY_DATE_COL = :b2
SQL piszę w ten sposób:
SET MY_NUMBER_COL = TO_NUMBER( :b1 )
, MY_DATE_COL = TO_DATE( :b2 , 'YYYY-MM-DD HH24:MI:SS')
i dostarcz ciągi znaków jako zmienne wiązania.
Takie podejście ma kilka zalet.
Jednym z nich jest obejście problemów i błędów, które można napotkać przy wiązaniu innych typów danych.
Kolejną zaletą jest to, że wartości wiązania są łatwiejsze do odszyfrowania w śledzeniu zdarzenia Oracle 10046.
Ponadto PLAN WYJAŚNIENIA (wierzę) oczekuje, że wszystkie zmienne wiązania będą VARCHAR2, co oznacza, że wyjaśniana instrukcja jest nieco inna niż faktycznie wykonywana instrukcja (ze względu na niejawne konwersje danych, gdy typy danych argumentów wiązania w rzeczywistym oświadczenie nie jest VARCHAR2.)
I (mniej ważne), kiedy testuję instrukcję w TOAD, łatwiej jest po prostu wpisywać łańcuchy w polach wejściowych i nie musieć trudzić się zmianą typu danych na liście rozwijanej.
Pozwalam również, aby wbudowane funkcje TO_NUMBER i TO_DATE sprawdzały poprawność danych. (Przynajmniej we wcześniejszych wersjach Oracle napotkałem problemy z bezpośrednim wiązaniem wartości DATE, co ominęło (przynajmniej niektóre) sprawdzanie poprawności i pozwoliło na przechowywanie nieprawidłowych wartości dat w bazie danych.
To tylko osobiste preferencje, oparte na przeszłych doświadczeniach. Używam tego samego podejścia z Perl DBD.
Zastanawiam się, co Tom Kyte (asktom.oracle.com) ma do powiedzenia na ten temat?
