Programowanie w języku Java - gdzie należy przechowywać instrukcje SQL? [Zamknięte]

Gdzie aplikacja zgodna z JDBC powinna przechowywać swoje instrukcje SQL i dlaczego?

Do tej pory udało mi się zidentyfikować te opcje:

• Zakodowane na stałe w obiektach biznesowych
• Osadzone w klauzulach SQLJ
• Hermetyzuj w oddzielnych klasach, np. Obiekty dostępu do danych
• Oparte na metadanych (oddziel schemat obiektu od schematu danych - opisz mapowania między nimi w metadanych)
• Pliki zewnętrzne (np. Pliki właściwości lub zasobów)
• Procedury składowane

Jakie są „zalety” i „wady” każdego z nich?

Czy kod SQL powinien być uważany za „kod” czy „metadane”?

Czy procedury składowane powinny być używane tylko do optymalizacji wydajności, czy też stanowią uzasadnioną abstrakcję struktury bazy danych?

Czy wydajność jest kluczowym czynnikiem przy podejmowaniu decyzji? A co z uzależnieniem od dostawcy ?

Co jest lepsze - luźne połączenie czy ciasne połączenie i dlaczego?

EDITED: Dziękuję wszystkim za odpowiedzi - oto podsumowanie:

Oparte na metadanych, tj. Mapowanie relacyjne obiektu (ORM)

Plusy:

• Bardzo abstrakcyjny - serwer DB można przełączyć bez konieczności zmiany modelu
• Szerokie - praktycznie standard
• Zmniejsza ilość potrzebnego kodu SQL
• Może przechowywać SQL w plikach zasobów
• Wydajność jest (zwykle) akceptowalna
• Podejście oparte na metadanych
• (Baza danych) niezależność dostawcy

Cons:

• Ukrywa SQL i prawdziwe intencje programistów
• SQL trudny do przejrzenia / zmiany przez DBA
• SQL może być nadal potrzebny w dziwnych przypadkach
• Może wymusić użycie zastrzeżonego języka zapytań, np. HQL
• Nie nadaje się do optymalizacji (abstrakcji)
• Może brakować referencyjnej integralności
• Zastępuje brak znajomości języka SQL lub brak dbałości o kod w bazie danych
• Nigdy nie dopasowuj wydajności natywnej bazy danych (nawet jeśli jest blisko)
• Kod modelu jest bardzo ściśle powiązany z modelem bazy danych

Zakodowane na stałe / zamknięte w warstwie DAO

Plusy:

• SQL jest przechowywany w obiektach uzyskujących dostęp do danych (hermetyzacja)
• SQL jest łatwy do napisania (szybkość rozwoju)
• SQL można łatwo wyśledzić, gdy wymagane są zmiany
• Proste rozwiązanie (bez bałaganu w architekturze)

Cons:

• SQL nie może być sprawdzany / zmieniany przez DBA
• SQL prawdopodobnie stanie się specyficzny dla bazy danych
• SQL może stać się trudny do utrzymania

Procedury składowane

Plusy:

• SQL przechowywany w bazie danych (blisko danych)
• SQL jest analizowany, kompilowany i optymalizowany przez DBMS
• SQL jest łatwy do przeglądu / zmiany dla administratora
• Zmniejsza ruch sieciowy
• Zwiększone bezpieczeństwo

Cons:

• SQL jest powiązany z bazą danych (blokada dostawcy)
• Kod SQL jest trudniejszy do utrzymania

Pliki zewnętrzne (np. Pliki właściwości lub zasobów)

Plusy

• SQL można zmienić bez konieczności przebudowywania aplikacji
• Oddziela logikę SQL od logiki biznesowej aplikacji
• Centralne repozytorium wszystkich instrukcji SQL - łatwiejsze w utrzymaniu
• Łatwiejsze do zrozumienia

Cons:

• Kod SQL może stać się nie do utrzymania
• Trudniej sprawdzić kod SQL pod kątem błędów (składni)

Osadzone w klauzulach SQLJ

Plusy:

• Lepsze sprawdzanie składni

Cons:

• Zbyt ściśle wiąże się z Javą
• Niższa wydajność niż JDBC
• Brak dynamicznych zapytań
• Nie tak popularne

Zwykle im bardziej aplikacja rośnie pod względem rozmiaru i / lub możliwości ponownego wykorzystania, tym większa potrzeba eksternalizacji / abstrakcji instrukcji SQL.

Zakodowanie na stałe (jako statyczne stałe końcowe) jest pierwszym krokiem. Przechowywany w pliku (properties / plik xml) to kolejny krok. Oparty na metadanych (tak jak jest to robione przez ORM, taki jak Hibernate / JPA) jest ostatnim krokiem.

Hardcoded ma tę wadę, że Twój kod prawdopodobnie stanie się specyficzny dla bazy danych i musisz go przepisać / przebudować / redystrybuować przy każdej zmianie. Zaletą jest to, że masz to w 1 miejscu.

Przechowywanie w pliku ma tę wadę, że może stać się nie do utrzymania, gdy aplikacja się rozrośnie. Zaletą jest to, że nie musisz przepisywać / przebudowywać aplikacji, chyba że musisz dodać dodatkową metodę DAO.

Wadą opartą na metadanych jest to, że kod modelu jest bardzo ściśle powiązany z modelem bazy danych. Przy każdej zmianie w modelu bazy danych będziesz musiał przepisać / przebudować / ponownie rozpowszechnić kod. Zaletą jest to, że jest bardzo abstrakcyjny i można łatwo przełączyć się z serwera DB bez konieczności zmiany modelu (ale zadaj sobie teraz pytanie: jak często firma miałaby przełączać się z serwera DB? Prawdopodobnie przynajmniej raz na 3 lata, prawda? t to?).

Nie będę nazywać procedur składowanych „dobrym” rozwiązaniem tego problemu. Mają zupełnie inny cel. Mimo to, twój kod byłby zależny od używanej bazy danych / konfiguracji.

Nie wiem, czy to jest optymalne, ale z mojego doświadczenia wynika, że ​​kończą one na sztywno (tj. Literały String) w warstwie DAO.

Nie sądzę, aby ktokolwiek podał Ci taki stan za / przeciw, jaki chcesz, ponieważ jest to dość duże pytanie. Zamiast tego tutaj jest to, czego używałem w przeszłości i czego będę używał w przyszłości.

Używam kodu SQL zapisanego na stałe w DAL. Myślałem, że to jest w porządku, dopóki DBA nie chcieli bawić się SQL. Następnie musisz go wykopać, sformatować i przesłać do administratorów baz danych. Kto się z tego wyśmieje i wszystko zastąpi. Ale bez ładnych znaków zapytania lub znaków zapytania w niewłaściwej kolejności i pozostawienie go z powrotem w kodzie Java.

Użyliśmy również ORM i chociaż jest to świetne rozwiązanie dla programistów, nasi administratorzy baz danych nienawidzili go, ponieważ nie ma SQL, z którego mogliby się śmiać. Użyliśmy także dziwnego ORM (niestandardowego od zewnętrznego dostawcy), który miał zwyczaj zabijania bazy danych. Używam JPA od tamtej pory i było świetnie, ale zrobienie czegoś skomplikowanego przy użyciu go poza DBA to bitwa pod górę.

Teraz używamy procedur składowanych (z instrukcją call zakodowaną na stałe). Teraz pierwszą rzeczą, na którą wszyscy będą narzekać, jest to, że jesteś przywiązany do bazy danych. Ty jesteś. Jednak jak często zmieniałeś bazę danych? Wiem na pewno, że po prostu nie mogliśmy nawet tego spróbować, ilość innego kodu zależnego od tego, plus ponowne przeszkolenie naszych administratorów baz danych i migracja danych. Byłaby to bardzo kosztowna operacja. Jeśli jednak w twoim świecie wymagana jest zmiana DB w mgnieniu oka, SP prawdopodobnie się wyczerpią.

Idąc dalej, chciałbym używać procedur składowanych z narzędziami do generowania kodu do tworzenia klas Java z pakietów Oracle.

Edytuj 2013-01-31 : Kilka lat i administratorzy baz danych później, a teraz używamy Hibernacji, przechodząc do SQL (procesy przechowywane w bazie danych) tylko wtedy, gdy jest to absolutnie konieczne. Myślę, że to najlepsze rozwiązanie. W 99% przypadków bazy danych nie muszą martwić się o SQL, a 1% robią to w miejscu, w którym już czują się komfortowo.

Przy użyciu ORM (takich jak Hibernate), które mam nadzieję będzie miał żadnych instrukcji SQL martwić. Wydajność jest zwykle akceptowalna, a także niezależność od dostawcy.

Czy kod SQL powinien być uważany za „kod” czy „metadane”?

Kod.

Czy procedury składowane powinny być używane tylko do optymalizacji wydajności, czy też stanowią uzasadnioną abstrakcję struktury bazy danych?

Procedury składowane umożliwiają ponowne użycie, w tym w innych procedurach składowanych. Oznacza to, że możesz odbyć jedną podróż do bazy danych i zlecić jej wykonanie instrukcji pomocniczych - najmniejszy ruch jest idealny. ORM lub sproc, czasu na kablu idącym do db i z powrotem nie można odzyskać.

ORM nie nadaje się do optymalizacji ze względu na swoją abstrakcję. IME, ORM oznacza również brak integralności odniesień - utrudniają raportowanie z bazy danych. To, co zostało zaoszczędzone na złożoności, teraz wzrosło, aby móc wydobyć dane w praktyczny sposób.

Czy wydajność jest kluczowym czynnikiem przy podejmowaniu decyzji? A co z uzależnieniem od dostawcy?

Nie, prostota jest. Blokada dostawcy ma miejsce również w przypadku bazy danych - SQL jest stosunkowo ustandaryzowany, ale nadal istnieją sposoby działania specyficzne dla dostawcy.

Strach przed zablokowaniem sprzedawcy w świecie Java jest interesujący.

Mam nadzieję, że nie zapłaciłeś 50000 USD za procesor za Oracle Enterprise, a potem użyłeś tylko najmniejszego wspólnego mianownika, aby przejść na MySQL w każdej chwili. Jak powie każdy dobry administrator danych, istnieją subtelne różnice między różnymi popularnymi bazami danych, szczególnie w odniesieniu do modeli blokowania i sposobu, w jaki osiągają one spójność.

Dlatego nie podejmuj decyzji, jak zaimplementować wywołania SQL, opierając się wyłącznie na zasadzie niezależnego od dostawcy SQL - miej prawdziwy (biznesowy) powód, aby to zrobić.

SQL wewnątrz procedur składowanych jest optymalizowany przez system bazy danych i kompilowany pod kątem szybkości - to jest jego naturalne miejsce zamieszkania. SQL jest rozumiany przez system bazy danych, analizowany przez system bazy danych. Jeśli możesz, przechowuj swój SQL w bazie danych; opakuj go w procedury składowane lub funkcje lub jakiekolwiek jednostki logiczne, które zapewnia system bazy danych, i wykonaj proste wywołania do niego, używając dowolnego z narzędzi wymienionych przez Ciebie lub kogokolwiek innego.

Po co przechowywać kod SQL systemu bazy danych poza bazą danych? Często ze względu na szybkość rozwoju. Dlaczego warto korzystać z mapowania ORM? - Niektórzy twierdzą, że mapowanie ORM zapewnia kompatybilność z różnymi systemami baz danych; jednak rzadko w prawdziwym świecie aplikacja odsuwa się od platformy bazodanowej, na której została zbudowana, zwłaszcza gdy zaczyna korzystać z zaawansowanych funkcji, takich jak replikacja, aw rzadkich przypadkach zdarza się, że system bazy danych jest wymieniany, pewna praca jest uzasadniona . Uważam, że jedną z wad ORMa często zastępuje brak znajomości języka SQL lub brak dbałości o kod w bazie danych. Ponadto ORM nigdy nie dorówna wydajności natywnej bazy danych, nawet jeśli jest blisko.

Stoję po stronie utrzymywania kodu SQL w bazie danych i wykonywania prostych wywołań do niego za pośrednictwem dowolnego interfejsu API lub interfejsu, którego chcesz użyć. Oddal również punkt, w którym wykonywane są wywołania bazy danych, umieszczając te wywołania za abstrakcyjną klasą lub interfejsem OO (wyrażonym za pomocą metod), więc jeśli kiedykolwiek dokonasz wymiany w nowym rodzaju źródła danych, będzie to bezproblemowe w warstwie biznesowej .

Jedyne pytanie, które zadajesz, na które można odpowiedzieć, brzmi: „Czy kod SQL czy metadane?” Z całą pewnością jest to kod i jako taki powinien być utrzymywany w jakimś rodzaju kontroli kodu źródłowego i mieć system umożliwiający łatwe aktualizowanie do najnowszej wersji i wycofywanie, gdy nie jest, jeśli coś pójdzie nie tak.

Widziałem trzy sposoby wykonywania SQL w aplikacji i każdy z nich ma swoje wady i zalety. Nie ma najlepszego sposobu, ale najlepiej jest po prostu wybrać taki, który dobrze działa z Twoją aplikacją i trzymać się go.

• ORM - ogranicza to ilość kodu SQL, który musisz napisać, i obsługuje wiele szczegółów za Ciebie. Będziesz musiał wykonać niestandardowy SQL. Upewnij się, że masz ORM, który radzi sobie z tym wdzięcznie.
• Obiekty dostępu do danych - zachowaj SQL w obiektach, które mają dostęp do danych. To hermetyzuje bazę danych i sprawia, że ​​reszta aplikacji nie musi wiedzieć o podstawowej strukturze bazy danych, tylko o interfejsie do tych obiektów.
• Procedury składowane - dzięki temu cała Twoja baza danych jest przechowywana w bazie danych, a administratorom łatwo jest wiedzieć, co się dzieje. Wszystko, co musisz zrobić, to wywołać przez kod przechowywane procesy

Zdarza się, że używamy mappera iBatis SQL, który jest bliżej metalu niż ORMy, takie jak Hibernate. W iBatis umieszcza się instrukcje SQL w plikach zasobów (XML), które muszą znajdować się w ścieżce klas.

Twoja lista podejść wydaje się dość obszerna, jeśli dodasz opcję ORM @ ocdecio. Powiedziałbym, że użycie ORM i użycie programu mapującego SQL i plików zasobów to dwa najlepsze podejścia. Unikałbym SQLJ, który nie jest zbyt popularny i zbyt mocno wiąże Cię z Javą. Trzymaj się również z dala od procedur składowanych, ponieważ wiążą one Cię z określonym dostawcą bazy danych (standardy dla procedur składowanych prawie nie istnieją).

Jak większość z nas, widziałem cały gamut, ale musimy uznać SQL za język pierwszej klasy. Widziałem nawet SQL przechowywany w DB, który jest ściągany, a następnie wykonywany z powrotem.

Najbardziej udane systemy, jakie widziałem, wykorzystują procedury składowane, funkcje i widoki.

Przechowywane procesy zachowują tekst SQL z powrotem w DB i pozwalają na stosunkowo natychmiastową zmianę przez tych, którzy WSTĘPUJĄ I DOSTOSUJEMY (co wymaga dużo odpowiedniego projektu, aby je obsługiwać).

Wszystkie rzuty powinny być za pośrednictwem widoków i prostych wyborów z tych samych powodów, cała logika projekcji powinna być zawarta w widoku.

Sugeruję użycie DAO z układem fabrycznym. Przykładowymi obiektami, których potrzebujesz, byłyby:

public class CoolBusinessObject
public class DAOFactory.java
public implementation CoolBusinessOjectDAO
public class CoolBusinessOjectDAOOracleImpl implements CoolBusinessOjectDAO

Ten styl warstwuje interakcję danych, więc w przypadku zmiany bazy danych lub przejścia na technologie ORM należy zmienić tylko jedną warstwę kodu.

Tak naprawdę nie ma żadnej znaczącej różnicy między tymi trzema:

1. Zakodowane na stałe w obiektach biznesowych
2. Osadzone w klauzulach SQLJ
3. Hermetyzuj w oddzielnych klasach, np. Obiekty dostępu do danych

Zakładam, że zamierzasz osadzić kod SQL w postaci ciągu bezpośrednio w kodzie Java. Podczas gdy 1 i 3 prawdopodobnie będą bezpośrednio używać JDBC (lub jakiegoś narzędzia, takiego jak Apache DbUtils ), 2 dodaje technologię preprocesora do stosu, generując odpowiedni kod JDBC przed kompilacją.

Więc zasadniczo, jeśli te rozwiązania obejmują osadzanie SQL, równie dobrze możesz użyć dowolnej z następujących technologii:

• JPA Criteria API , modelowanie JPQL jako wewnętrznego języka specyficznego dla domeny w Javie
• jOOQ , modelowanie SQL jako wewnętrznego języka specyficznego dla domeny w Javie

Mogą istnieć również inne narzędzia, które pomogą Ci osadzić SQL w Javie w sposób bardziej bezpieczny dla typów niż za pomocą SQLJ lub poprzez rzeczywistą konkatenację ciągów.

Z mojego doświadczenia wynika, że ​​twarde kodowanie instrukcji sql w obiektach DAO jest tym, co jest szeroko stosowane, chociaż myślę, że powinna być najmniej preferowaną metodą. Najlepszą praktyką powinno być przechowywanie instrukcji sql w pliku właściwości. Pobierz instrukcje w obiekcie DAO za pośrednictwem interfejsu do plików właściwości, na przykład java.util.Properties . Instrukcje sql można przeplatać znakami „?” W celu przekazania parametrów za pomocą metody Prepared Statement .

Takie podejście pomaga oddzielić logikę sql od logiki biznesowej aplikacji. Dzięki temu dostępne jest centralne repozytorium wszystkich instrukcji sql, co ułatwia modyfikację, eliminując potrzebę wyszukiwania instrukcji bazy danych w logice aplikacji, a także zwiększa zrozumiałość.

Moje trafiają do paczek zasobów. Wiem, że to nie jest normalne, ale jest to najłatwiejsze do utrzymania dla mnie i każdego „poza mną”. To proste i logiczne.

Właściwie jestem ciekawa, czy ktoś również zastosuje moje podejście.

Jako rexem napisał, instrukcje SQL są kodem - powinny być traktowane jak kod, a nie eksternalizowane (chyba, że ​​masz dobry powód), ale umieszczane z kodem przetwarzającym dane SQL z / do tych instrukcji. Dzisiejsze ramy ORM / iBatis oferują wiele uproszczeń w codziennym rozwoju JDBC.

Odpowiedzi na swoje pytanie znajdziesz w tym pytaniu :) Problem, w jaki sposób będą przechowywane Twoje statystyki SQL, zależy od króla Twojej aplikacji. Jakie są Twoje potrzeby? Wysokie bezpieczeństwo, łatwość pisania kodu lub konserwacji, wieloplatformowość lub blokada dostawcy? Następne pytanie, czy potrzebujesz czystego środowiska SQL lub ORM, będzie dobre?

* Hardcoded in business objects
* Encapsulate in separate classes e.g. Data Access Objects

Najprostsze rozwiązanie (P), trudne w utrzymaniu (C)

* Embedded in SQLJ clauses

Lepsze sprawdzanie składni (P), brak dynamicznych zapytań (C), niższa wydajność niż JDBC (C), nie tak popularne (C)

* Metadata driven (decouple the object schema from the data schema - describe the mappings between them in metadata)

To musi być konkretny przypadek, w którym powinieneś to zrobić (C) lub jeśli masz na myśli ORM (P);)

* External files (e.g. Properties or Resource files)

Łatwy do utrzymania (P), ale trudniejszy do sprawdzenia pod kątem błędów (C)

* Stored Procedures

Wysoki poziom bezpieczeństwa (P), kod trudny do utrzymania problemów z blokadą dostawcy (C)