Results 1 to 14 of 14

Thread: Database met inheritence

  1. #1

    Database met inheritence

    Hallo hallo,

    In de documentatie van PostgreSQL las ik dat je ook gebruik kunt maken van table inheritence, alleen dat dit nog niet helemaal optimaal is. Zijn er andere database systemen die inheritence ondersteunen?

    Bij voorbaat dank!

  2. #2
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Bedoel je via Delphi of de database-server zelf?
    Delphi is great. Lazarus is more powerfull

  3. #3
    Ik bedoel de database zelf. In Postgres kun je bijvoorbeeld een tabel "persoon" en een tabel "medewerker" hebben die erft van persoon. Als je een medewerker insert dan kun je deze ook zien als je een SELECT * FROM persoon doet. In principe werkt dit bij Postgres alleen zijn er wat beperkingen waardoor het eigenlijk niet bruikbaar is in veel gevallen. De beperkingen liggen, als ik het goed begrijp, vooral in de constraints die niet over meerdere tabellen gaan.

  4. #4
    Volgens mij kan je Oracle wel soortgelijke dingen doen. Je kan bepaalde types overerven, en je kan tabellen baseren op object types. Of je tabellen ook kan baseren op overerfbare types weet ik niet uit m'n hoofd.

    Maar zoiets zal dan in ieder geval niet precies hetzelfde werken. De vraag is waarom je zoiets zou willen. Lijkt me handiger om dit in een laagje hoger op te lossen door bijvoorbeeld wijzigingen op te slaan in zowel persoon als medewerker (als je een middle tier hebt, bijvoorbeeld in de vorm van KBMmw), door medewerker een extension table van persoon te maken, of door persoon een (materialized) view te maken.
    1+1=b

  5. #5
    De vraag is waarom je zoiets zou willen
    Omdat hier volgens mij veel voordelen aan zitten, net als inheritence in Delphi. Momenteel moet ik eerst persoon joinen met medewerker om alle gegevens te krijgen over een medewerker zoals voornaam, geboorte datum e.d. Ook bij een insert moet je weer bepalen welk veld naar welke tabel weggeschreven moet worden. Kbmmw ondersteund het resolven van joins wel, maar het zou simpeler zijn als het geen join was, maar gewoon een tabel.

    Postgres ondersteund wel updatable views, maar die mogen slechts één tabel in de FROM hebben. Die link met de extension table info is wel interessant, maar ik heb krijg de indruk dat dit een soort impleciete view/query is en dat deze niet te updaten is.

  6. #6
    *+E13818MU01F0F* Norrit's Avatar
    Join Date
    Aug 2001
    Location
    Landgraaf
    Posts
    967
    Voordelen?

    Dus je wil al je business logica in de database gaan stoppen.
    Dan moet je het ook consequent doorvoeren en data goed zetten in stored procedures en triggers. Want dat is dan ook simpeler als je daar in code niet over na hoeft te denken...
    Objective reality is a delirium caused by lack of alcohol in blood

  7. #7
    Dus je wil al je business logica in de database gaan stoppen.
    Nee, dat was ik niet van plan. Ik snap eigenlijk ook niet wat business logica met database inheritence te maken heeft? Als ik in Delphi een TMedewerker heb en een TPersoon dan laat ik medewerker ook erven van TPersoon. Ik zie niet in waarom je dat niet zou (moeten) willen in een database.

    Ik zeg niet dat je iedere join als een soort type (view, extensiontable etc.) in je database moet hebben, maar in het geval van een subtype zoals medewerker en persoon zie ik daar wel de voordelen van in. Dit zijn bij namelijk ook de "joins" die ge-insert en ge-update moeten worden. Bij mijn overige joins is dat over het algemeen niet het geval.

  8. #8
    *+E13818MU01F0F* Norrit's Avatar
    Join Date
    Aug 2001
    Location
    Landgraaf
    Posts
    967
    Dan nog is en blijft het business logica, wat niet in de database thuis hoort.
    En in code laat je inderdaad je TMedewerker van TPersoon overerven, maar doe je in je constructor wel allerlei zaken om dingen goed te zetten, misschien zelfs al een standaard waarde selecteren uit de tabel aanspreektitels (waar je dan weer een default optie in hebt welke niet vast is).
    Waar zit dan je verschil met database triggers die dat voor je doen?
    Objective reality is a delirium caused by lack of alcohol in blood

  9. #9
    Dan nog is en blijft het business logica, wat niet in de database thuis hoort.
    Dat business logica niet in je database thuis hoort ben ik ben je eens. Ik ben het alleen niet met je eens dat table inheritence in je database logica is. Het is naar mijn idee meer een ontwerp keuze.

    Ik krijg de indruk dat we langs elkaar heen "praten". Ik kan nog steeds in de middleware van alles met het TPersoon of TMewewerker object doen, zoals valideren, default waardes zetten e.d. Het enige is dat bij een select, update, delete of insert ik niet hoef te joinen. Ik zie dan ook niet in wat het verschil is tussen een join ophalen van persoon en medewerker en vervolgens default waardes zetten of direct een tabel ophalen medewerker die erft van persoon en daar default waardes op zetten. Het enige verschil in mijn optiek is dat je niet hoeft te joinen wat de zaak aanzienlijk simpeler maakt, zeker bij inserts en updates. In de database zelf zit natuurlijk wel wat logica om dit mogelijk te maken, maar dat is functionaliteit van de database zelf en geen applicatie logica.

  10. #10
    *+E13818MU01F0F* Norrit's Avatar
    Join Date
    Aug 2001
    Location
    Landgraaf
    Posts
    967
    Nee, we praten niet langs elkaar door
    Mijn mening is dat inheritence niet in de database als zodanig thuis hoort.

    Laat het me anders zeggen:
    Stel je implementeert deze inheritence met je PostgreSQL
    Idealiter zit dit in een gescheiden laag die je kan veranderen, dus als ik daar MSSQL van wil maken moet dat kunnen.
    In jouw geval kan dat dus niet zonder slag of stoot.

    Alleen dit voorbeeld is voor mij al genoeg om te zeggen dat inheritence zoals jij beschrijft business logica is en dus niet in de database thuis hoort.
    Objective reality is a delirium caused by lack of alcohol in blood

  11. #11
    Idealiter zit dit in een gescheiden laag die je kan veranderen, dus als ik daar MSSQL van wil maken moet dat kunnen.
    In jouw geval kan dat dus niet zonder slag of stoot.
    Begrijp ik je goed dat het bij jou zo opgezet is dat je er een databasemigratie tool/script overheen haalt en klaar zonder één regel code te veranderen aan je applicatie?

    Alleen dit voorbeeld is voor mij al genoeg om te zeggen dat inheritence zoals jij beschrijft business logica is en dus niet in de database thuis hoort.
    Volgens deze redenering kun je dan waarschijnlijk veel meer zaken niet gebruiken. Bijvoorbeeld een bepaald type index, datatype, autoincrement, transacties e.d. Als je de grootste gemene deler wilt vinden tussen al deze systemen omdat je eventueel in de toekomst gaat switchen lijkt me onwerkbaar.

    Door inheritence te gebruiken of welke andere exotische mogelijkheden dan ook kun je wel een afhankelijk creëren tussen je applicatie en de database, maar dat dit direct business logica is naar mijn mening niet juist. Ik vind die afhankelijkheid tot op zekere hoogte geen probleem. In mijn applicatie probeer ik zoveel mogelijk afhankelijkheden te vermijden, maar dit heeft meestal ook een prijs. In dit inheritence geval zou ik er wel voor kiezen als het 100% zou werken, maar dat doet het momenteel nog niet in Postgres.

  12. #12
    *+E13818MU01F0F* Norrit's Avatar
    Join Date
    Aug 2001
    Location
    Landgraaf
    Posts
    967
    Ik heb het niet over zonder 1 regel code te wijzigen. Er zijn altijd wel wat syntactische dingen die anders zouden kunnen zijn, maar in structuur zijn de objecten die naar buiten toe gaan wel transparant. Een TMedewerker wordt in de business opgebouwd uit de TMedewerker en de TPersoon, en daar als 1 object naar buiten toe gezet.
    Ik zou het simpelweg belachelijk vinden dat ik altijd TPersoon ophaal bij een select * from TMedewerker. Daar vraag ik niet om. Dus als ik specifiek alleen de TMedewerker wil ophalen moet ik dat uitzetten als select veld1, veld2, veld3, veld4, veld5 from TMedewerker. En wat gebeurd onder water, is Postgress zo slim om dan te zeggen dat ik niets van TPersoon wil of doet hij stiekem toch een join om die daarna doodleuk overboord te gooien?

    En dan over dingen waarvan je denkt dat het business logica is:
    Index heeft niets met business logica van doen, het is gewoon tooling om de database te optimaliseren en dus een noodzakelijk iets. Maar is er een database die geen index ondersteund gaat de applicatie in ieder geval niet over zijn nek
    Datatype heeft ook niets met business logica te maken, of ik nu een PostgresInt of een MssqlInt naar int vertaal, boeien
    Autoincrement is de enige discutabele, maar aangezien iedere database dit ondersteund vind ik het gezegend. Dit zou ik overigens heel makkelijk in de business in een presave kunnen ondervangen, maar dit hangt er weer vanaf hoe generiek je eigen opzet is.
    Transacties? Serieus? Sinds wanneer gebruik jij transacties rechtstreeks in je datalaag. Die zitten in je business verscholen, aangezien die de enige is die weet wat binnen de transactie moet gebeuren.

    Voor wat ik lees ben je allemaal excuses aan het zoeken voor jezelf om maar te verantwoorden dat table inheritence een goed iets is.
    Ik deel deze mening simpelweg niet, maar dat maakt ook niet uit.
    Je weet mijn standpunt in deze, daar laat ik het dan ook verder bij.
    Lijkt me niet dat dit iets is wat we in deze thread nog verder moeten uitdiepen want het heeft met je oorspronkelijke vraag niets meer van doen.
    Objective reality is a delirium caused by lack of alcohol in blood

  13. #13
    Quote Originally Posted by luigi View Post
    Als ik in Delphi een TMedewerker heb en een TPersoon dan laat ik medewerker ook erven van TPersoon.
    Dat betwijfel ik al. Van een medewerker wil ik andere gegevens weten dan van een klant. Bovendien gebruik ik de gegevens nooit op dezelfde manier. Ik heb er dus vrijwel geen baat bij om een medewerker af te leiden van persoon.

    Als ik dat al zou willen, en als ik dat al zo in de database op zou willen slaan, dan zou ik kiezen voor een van deze:

    1. Losse tabellen voor bijvoorbeeld Klant en Medewerker. Een view Persoon kan simpelweg een union (of union all) doen.
    2. Extension tables. Een tabel Persoon bevat de basisgegevens (naam?). Een tabel Medewerker bevat een PersoonId, en de extra velden die het een medewerker maken.

    Potentieel voordeel van de tweede oplossing:
    - Je kan personen registeren zonder afgeleide.
    - Je kan personen registeren met meedere afgeleiden. Iemand kan bijvoorbeeld medewerker en klant zijn, door in beide extension tables gegevens toe te voegen voor de persoon.

    Overigens ben ik het niet met Norrit eens dat dit business logic is. Het is gewoon een manier van opslaan. Als jij een medewerker wil opslaan, dan zou die logica ergens moeten leven in de rand van de applicatie, en niet of nauwelijks uit moeten maken of dit uberhaupt in een database gebeurt (of in bestand, via een API, ofwat dan ook), laat staan hoe die data precies is ingedeeld (losse tabellen, tabel met inheritance, of gewoon een blob met XML of Json er in). Daarmee wil ik niet zeggen dat het een goed idee is. Het lijkt mij een rare, gekunstelde feature, en ik zou liever voor een oplossing gaan die wat beter te begrijpen is. Maar als je je hier prettig bij voelt moet je er vooral voor gaan, natuurlijk. Alles kan, en het is niet aan ons om te bepalen wat moet en wat niet. Zo'n feature wordt ook niet voor niets gebouwd. Er is vast een doelgroep voor, en jij bent blijkbaar iemand uit die doelgroep.
    1+1=b

  14. #14
    De discussie gaat nu meer over ontwerpkeuzes en wat in welke laag thuis hoort, en of je wel of niet moet overerven. Wat ik merk is dat iedereen hier andere ideeën over heeft met bijbehorende argumenten, soms kan ik mij in die argumenten vinden en soms niet. Kijk alleen al naar dit topic waar toch twee ervaren programmeurs het al niet eens zijn over of iets wel of geen business logic is.

    Bedankt voor de feedback!

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •