Verwijderd schreef op zaterdag 29 januari 2005 @ 02:48:
ik heb even gegoogeld en ik weet dat er voor databanken mooie dingen zijn zoals hybernate maaar aangezien ik nog tamelijk noob ben heb ik dus mijn layer als volgt gemaakt
acces klasse en dan voor al mijn tabelen een klasse apart
Dit is geen werk voor beginners. Een data access layer maken met O/R mapping technologie lijkt simpel maar je bent een inmense hoeveelheid tijd kwijt om het goed te krijgen en als beginner verzandt je al snel. Geloof me, de vraag die jij stelt is een simpele, je bent nog niet eens toe aan de wat complexere zaken zoals een graph saven in de juiste volgorde, change tracking etc. etc. Ik wil je niet ontmoedigen, maar om programmeren/java te leren lijkt me het zinvoller om gewoon MET een O/R mapper te gaan werken, bv Hibernate, en dan, mocht je nieuwsgierig zijn, te kijken hoe het in hibernate is opgelost, het is open source tenslotte. Je zult zien dat het tamelijk complex is.
nu zit ik met volgend probleem ik moet in sql een join doen over 3 tabellen moet ik hiervoor dan een aparte klasse maken (dus een klasse waarin ik het logisch verband tussen die 3 klassen leg), een zoektocht op google leverde bijna altijd links op naar hybernate
Je moet eerst dingen definieren alvorens je dit op kunt lossen: wat is een entity, wat is een entity representatie, waar sla ik representatie <-> DDL meta data op, wat is een relatie tussen 2 entities...
Simpel? Nee niet echt. 9 van de 10 mensen denkt nl. dat een relatie tussen 2 entities echt bestaat, maar dat is niet het geval (attributes hebben een relatie en die attributes hebben weer een relatie met de attributes in de entities waarin ze zitten). Door inzicht te krijgen in deze materie, krijg je automatisch de oplossing aangereikt. Het probleem met relaties wordt opgelost door gemakshalve te zeggen "Customer heeft relatie met Order (1:n)" en "Order heeft relatie met customer (m:1)". 2 relaties waar je wellicht eigenlijk 1 dacht aan te treffen.
Om van operaties op entity representaties (je classes) naar DML in SQL te komen is vrij lastig. ten eerste moet je van entity representatie (je class) naar table oriented DML (een class kan 2 of meer tables in zich hebben). De operatie kan meerdere entity representaties omvatten (get me all customers with orders in June 2004).
Je gaat dan nadenken over hoe je dat zou willen formuleren. Aangezien je met sets werkt, moet je denken vanuit een set based wereld: in het voorbeeld wat ik net gaf heb je de set customers en de set orders en je wilt een subset van de set orders die je samenstelt mbv een subset uit de set orders. Zodoende kom je op je query language uit, dus hoe je je operaties op entities wilt formuleren (niet in collection.GetCustomers() denken, maar in een soort taal)
Wanneer je dat hebt geformuleerd zal je dus tegen het feit aanlopen dat je operaties wilt uitvoeren die meerdere entities omvatten, zoals in ons voorbeeld. Omdat je je taaltje al hebt geformuleerd weet je hoe je relaties moet aangeven. De feitelijke implementatie hangt af van hoe je met je core werkt: connected of disconnected. Bij een connected core, heb je in je code altijd een 'session' of 'context' bij de hand waarin de meta-data is opgeslagen. Die meta-data bevat informatie over de relaties tussen alle entities. Je kunt dan dus volstaan met het aangeven van welke van de bekende relaties je wilt gebruiken. Bij een disconnected core heb je dat niet en moet je de core de relatie aanreiken. Dit kan bv door een relatie class te definieren waarin je aangeeft welke fields van welke entities een relatie hebben, welke van de sides de PK side is en wat het type is van de relatie (als je je afvraagt waarom je moet aangeven welke side de PK side is, ga maar eens nadenken over 1:1 relaties
)
In ons voorbeeld is het dus zaak dat je je core aangeeft dat deze de relatie Customer - Order (1:n) gaat gebruiken. Dus de elementen die onze set filters omvatten zijn:
- Relatie: Customer - Order (1:n)
- Filter op Order.OrderDate: Order.OrderDate between 01-06-2004 AND 30-06-2004
- Set to return: Customer.*
Een DML SELECT operatie is net zo duidelijk:
SELECT <selectlist uit total set>
FROM <relaties te gebruiken om total set te bouwen>
WHERE <filters op total set>
Dus doe je:
Voor SELECT: SELECT <genereer hier alle fields van Customer, mbv meta data>
Voor FROM: pak de relatie(s). In dit geval Customer - Order. Je gaat gemakshalve even van de makkelijkste variant uit: CUSTOMER INNER JOIN ORDER (Customer - Order is 'weak', dus LEFT/RIGHT joins leveren andere resultaten op wellicht). Een INNER JOIN verlangt een ON clause, dus die genereer je mbv de relatie gegevens die je OF haalt uit de meta-data (connected) of uit de aangereikte relatie object (disconnected).
Voor WHERE: aangezien where clauses bestaan uit 'predicates' die genest kunnen zijn en altijd true of false opleveren kun je dit recursief genereren. we hebben hier 1 filter dus genereer je:
WHERE (Order.OrderDate BETWEEN @param1 AND @param2))
Je onderdelen zijn klaar en je plakt ze samen tot de query die je naar je query core stuurt.
Succes!
:strip_icc():strip_exif()/u/32734/crop5ee11f3ba965d_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/1857/crop5a4d06ced6afe_cropped.jpeg?f=community)
/u/26735/crop5b6e03049ac12.png?f=community)