abstract data layer
we zijn weer enkele topics verder en ik ben opnieuw mijn hoofd aan het breken over de Storage classen (zie vorige topics). Ik kwam tot de conclusie dat, hoe ik mijn storage momenteel opbouw, veel te omslachtig is.
Ik zocht dus een oplossing en zag de querybuilder van Doctrine dus ik dacht hé leuk hier kan ik wat mee. Dan was ik verder aan het denken en dan kwam ik tot de conclusie dat ik met doctrine alleen databases kan uitlezen via pdo (verbeter me als ik fout ben). Buiten de querybuilder niet veel voordeel tegenover wat ik nu heb dus ik dacht dit kan beter.
Ik begon aan een soort StorageBuilder. Die bevat ongeveer dezelfde properties als de Doctrine querybuilder maar deze genereert GEEN sql. Wat wil in nu net doen? Het storageBuilder object meegeven aan mijn Storage classe.
Code (php)
Cool, nu kan ik in elke storage classe alles ophalen via $sb->getFields(), $sbGetFrom() etc. From kan een db-tabel zijn maar evengoed een .yml of een .json. In princiepe zou ik met de eigenschappen van de storagebuilder overal moeten aangeraken.
Dan kwam ik op het volgende probleem, er bestaat zoiets als KOPPELTABELLEN. SQL kent iets dat een JOIN noemt, het probleem is no-sql storages kennen dat niet dus ik weet niet hoe ik de interactie tussen 2 tabellen / 2 bestanden moet koppelen.
Ik zou kunnen zeggen dat er eerst moet opgehaald worden uit tabel / bestand één en dan met de key uit die tabel + bestand gaan zoeken in de andere tabel / bestand.
Hoe los ik dit het beste op?
Bedankt voor het lezen!
Jasper
Gewijzigd op 15/02/2013 15:42:16 door Jasper DS
Misschien heb ik het helemaal verkeerd nu, maar moet je dan niet bijv een databaseStorageBuilder, JsonStorageBuilder etc hebben? Je zou volgens mij een interface kunnen maken die de benodigde methodes "aankaart" en deze implementeren in alle builders.?
Nee mijn "mapper" (waar de builder staat) is onafhankelijk van de storage. Het "builder" object (slechte naam) word meegeven aan een storage classe (PDO, Mysql, Json, XML, ...) die dan het object kan uitlezen en zijn storage specifieke ding kan doen zoals bijvoorbeeld een query maken.
Gewijzigd op 15/02/2013 21:57:23 door - Raoul -
Oke bedankt voor de tip maar hebben jullie ook een oplossing voor het join probleem tussen een SQL storage en een NO-sql storage?
Een storage interface maken en dan een SqlStorage of NoSqlStorage class die de Storage interface implementeert.
Gewijzigd op 15/02/2013 22:46:13 door Local Dev
- Raoul - op 15/02/2013 22:44:03:
Een storage interface maken en dan een SqlStorage of NoSqlStorage class die de Storage interface implementeert.
Dat is allemaal het probleem niet "simpele" query's zijn geen probleem. Het gaat mij over het join probleem. Hoe kan ik dat overeen laten komen tussen een sql en een nosql database?
Verder zou ik doen wat Raoul zegt, gebruik maken van een interface, en voor ieder type storage een database abstraction layer maken, of gebruik maken van Doctrine of Propel
Tegen welk probleem loop je aan met een join, kan je code laten zien?
Gewijzigd op 15/02/2013 23:12:30 door Local Dev
Gewoon gebruik maken van Doctrine lijkt me inderdaad ook een goede oplossing.
Je wilt toch niet met 1 enkele methode alles ophalen?
@reshad, die "Storagebuilder" is en class die alle gegevens bevat die de storage classe (kan een pdoStorage, XMLStorage, ... zijn) nodig heeft om een query / fileloader op te stellen.
Gewijzigd op 15/02/2013 23:21:29 door Jasper DS