[ALG] Content object definitie in database *

[Verwijderd]

Al enkele jaren fulltime bezig met het ontwikkelen van websoftware in PHP(5). Sinds wij meer dan een jaar PHP5 draait ontwikkel ik ook zoveel mogelijk volgens het OOP Principe. Nu moet er alleen een CMS ontwikkeld gaan worden en ik heb de voorkeur om hierin over te gaan stappen naar ASP.Net C#. Ik heb twee jaar ervaring met Classic ASP en MS SQL Server 2000 en heb een paar kleine dingetjes gedaan in ASP.Net C#.

De ideeën voor het CMS zijn eigenlijk al ongeveer rond. Er moet nog het e.e.a. uitgewerkt worden aan UI, UML en database ontwerp. Belangrijkste punt in dit ontwerp is dat wij generiek om willen gaan met content, en dus middels object definities in de database willen gaan werken. Dat maakt de oplossing complexer en zorgt voor extra denkwerk, maar aangezien wij op dit model een ecommerce oplossing hebben draaien (PHP5 en mySQL 5) en daar tevreden over zijn willen we deze stap toch maken. De Interface willen we Web 2.0 - achtig gaan maken. Reqeusts zulllen veelal via AJAX gaan lopen.

Nu hoor ik geluiden van: er zitten valkuilen in dit model (met name zoals we met data in de database om willen gaan). Maar ik zie niet wat dat nou kan zijn, en details hoor ik ook niet van mensen die dat roepen. Met de juiste Views en Stored Procedures zijn queries te minimaliseren en hoeft memorie gebruik niet groot te zijn. Zijn er mensen met negatieve ervaringen (en positieve) met dit model? Ik begrijp dat een 3rd party componenten als een O/R mapper niet te gebruiken is en je wellicht meer zelf moet uitwerken. Ik heb niet echt een zinnige discussie kunnen vinden over dit model (wellicht heb ik verkeerd gezocht) en is dit een mooie mogelijkheid om dit model te bespreken.

Verder ben ik ook wel benieuwd naar 3rd party componenten die beschikbaar zijn voor ASP.Net C#, zodat ik wellicht veel zaken sneller kan realiseren. Zijn hier overzichten van? Ik ben een redelijke newbe in de wereld van ASP.Net en C# en het is dus lastig om te bepalen wat je wel en niet kunt gebruiken. Voor wat tips/urls sta ik dus ook open!

[edit]

Nog een kleine vraag: is zo'n oplossing nu sneller te reailseren in ASP.Net dan PHP? Oftewel: bevat de .Net bibliotheek nu veel meer dan alle standaard methodes van PHP?

[ Voor 4% gewijzigd door Verwijderd op 16-07-2007 11:35 ]

[RobIII]

Verwijderd schreef op maandag 16 juli 2007 @ 11:32:
Nu hoor ik geluiden van: er zitten valkuilen in dit model (met name zoals we met data in de database om willen gaan). Maar ik zie niet wat dat nou kan zijn, en details hoor ik ook niet van mensen die dat roepen.

Dat lijkt me dan sowieso relevant om ze daar dan expliciet om te vragen

Maar ik vermoed wel te weten waar de kneep zit; je bent denk ik een database-in-een-database aan 't bouwen; hetgeen hier nog niet zo lang geleden besproken is.

Verder vind ik dat je niet erg concreet een probleem post of aangeeft wat je dan hebt waar problemen in zouden kunnen zitten. Gelieve dit wat te verduidelijken.

Verschillen/voordelen van ASP.Net C# of PHP5 enz. kun je prima googlen; de voordelen/nadelen ervan ook en een topic daarover loopt doorgaans uit op 'nietus! mijnes is beter!' en daar zie ik weinig heil in.

[ Voor 27% gewijzigd door RobIII op 16-07-2007 12:00 ]

[Verwijderd]

Die hadden het ook van horen zeggen

Had ik dus ook weinig aan, vandaar dat ik zelf naar een antwoord / discussie opzoek ben. Ik wacht op je link!

[edit 1]

De verschillen ken ik in grote lijn wel; het gaat me niet om 'de mijn is beter'. Belangrijk argument voor mijn keuze ASP.Net is integratie met Microsoft en beter inzetbaar voor intranet. Ik wil dus geen discussie wat is beter: maar is de .Net library nu groter of totaal anders dan binnen PHP of is dat te vergelijken?

[edit 2]

Een duidelijkere probleemstelling is voor mij lastig. Ik heb een paar geluiden opgevangen en daar wil ik het zijne van weten voor ik daadwerkelijk aan de slag ga!

[edit 3]

Nu ga ik het linkje lezen...

[ Voor 64% gewijzigd door Verwijderd op 16-07-2007 12:04 ]

[RobIII]

Verwijderd schreef op maandag 16 juli 2007 @ 12:00:
Die hadden het ook van horen zeggen

En sinds wanneer neem je zoiets serieus? Alsof dat een argument is!

De link is inmiddels gepost

Verwijderd schreef op maandag 16 juli 2007 @ 12:00:
[edit 1]

De verschillen ken ik in grote lijn wel; het gaat me niet om 'de mijn is beter'. Belangrijk argument voor mijn keuze ASP.Net is integratie met Microsoft en beter inzetbaar voor intranet. Ik wil dus geen discussie wat is beter: maar is de .Net library nu groter of totaal anders dan binnen PHP of is dat te vergelijken?

De .Net library is groter en compleet anders. Maar of dat nou een antwoord is waar je wat aan hebt...

Verwijderd schreef op maandag 16 juli 2007 @ 12:00:
[edit 2]

Een duidelijkere probleemstelling is voor mij lastig. Ik heb een paar geluiden opgevangen en daar wil ik het zijne van weten voor ik daadwerkelijk aan de slag ga!

Je hebt je collega's toch ook het probleem voorgelegd? Ik neem aan dat je al een ontwerp of iets dergelijks had? Je probleemstelling is gewoon te vaag om er iets concreets over te kunnen zeggen (behalve dan dat ik vrees dat mijn vermoeden(s) kloppen )

[ Voor 75% gewijzigd door RobIII op 16-07-2007 12:11 ]

[Verwijderd]

Zo, even het e.e.a. doorgelezen uit de thread. Ik heb aan jou wel de juiste persoon zo te lezen

Ik heb even een versimpeld db model geplaatst (overigens gemodelleerd voor mySQL), waar we veel van de besproken punten al in getackeld hebben. Enige nadeel is dat er een stukje softwarematige intelligentie aan de applicatie moet worden toegevoegd om de juiste data van een ObjectInstance op te halen. Dan is het de vraag: weegt dat op tegen de voordelen van het flexibel inrichten van de database. Ik vind het zo droevig om losse modules al vacature, nieuws en agenda te moeten maken: het is uiteindelijke allemaal tekst met een paar afwijkende attributen.



In dit model zie je dat een datum wel als datum wordt opgeslagen, dat geldt ook voor alle andere datatypen. Het is dus wel een stap verder dan jouw modelschets uit het andere topic. Maar goed: schiet er maar op.

Ik ben met name degene die dit zulk dingen verzint en uitwerkt. We zijn met een klein team (2 man, binnenkort 3) en moet ik ergens anders een klankbord zoeken! Je vermoedens kloppen deels dus wel: hetzij wel dat er (volgens mij) wel redelijk goed over nagedacht is...

[RobIII]

Mja, dit is dus nog een stap erger Het is gewoon een database-in-een-database. Als je dan toch zonodig 'dynamische' tabellen wil, laat je code dan gewoon DDL statements genereren; heb je hetzelfde effect maar dan beter

Zoals je in het aangehaalde topic kunt lezen ga je je straks helemaal scheel joinen en veel te complexe queries nodig hebben om een simpel berichtje (om maar eens wat te noemen) op te halen (laat staan inserten).

Maar here's an idea: gooi eens voor de test 10 berichten, 10 vacatures, 10 zussen en 10 zo-en in je database en ga ze dan weer eens op verschillende manieren ophalen (met Where clauses om 1 specifiek object op te halen, of 'lijsten' van overzichten van openstaande vacatures etc.). Dan ben je er zo achter hoe gaar dit model is

Verwijderd schreef op maandag 16 juli 2007 @ 12:33:
Ik vind het zo droevig om losse modules al vacature, nieuws en agenda te moeten maken: het is uiteindelijke allemaal tekst met een paar afwijkende attributen.

Eureka! Dan kan heel de wereld nu overstappen op jouw DB ontwerp Want er past alles in wat je kunt bedenken! Gek dat dat dan nog niet eerder bedacht is Oh...wacht... MySQL, Oracle, MSSQL, PostgreSQL en vele anderen lijken er wel verdacht veel op

[ Voor 89% gewijzigd door RobIII op 16-07-2007 12:55 ]

[Verwijderd]

Bedankt voor je heldere/cynische toon...

Best verhelderend en een trigger om te kijken hoe het op te lossen is als ik geautomatiseerd losse tabellen aanmaak per content type.

[RobIII]

Verwijderd schreef op maandag 16 juli 2007 @ 13:12:
Bedankt voor je heldere/cynische toon...

Mja, zo heeeel cynisch was het niet bedoeld. Even goeie vrienden
Laten we zeggen dat iedereen die wel eens met databases stoeit vroeger of later deze fout maakt (althans: grote kans )

[Verwijderd]

Zit nu even bij te komen van al het werk dat voor niets gedaan is

Ik zie het maar als visie verbreding dat dit niet helemaal de weg is die bewandeld moet worden. Het enige lastige is extenden van objecten. Stel dat je een vacature hebt voor een bepaalde locatie. Een locatie is in principe een object (naam, adres, beschrijving) en een vacature is ook een object (functie, salaris, uren, beschrijving), maar de vacature hoort bij een locatie/vestiging, en via de vestiging moet je ook de openstaande vacatures kunnen opvragen. Dit moet dynamisch vast te leggen zijn. Ik wil namelijk wel die flexibiliteit behouden van de oplossing zodat deze in principe voor elke (bijna elke) situatie te configureren is.

Dan is de vraag: moet je nog wel je object definitie vastleggen in de database zodat je relaties kan herleiden? Of lees je dat dynamisch uit?

[RobIII]

Verwijderd schreef op maandag 16 juli 2007 @ 13:37:
Dan is de vraag: moet je nog wel je object definitie vastleggen in de database zodat je relaties kan herleiden? Of lees je dat dynamisch uit?

Als je Fk gebruik die de ene keer uit tabel a komt en de andere keer uit tabel b dan kun je aan het "ID" niet zien welke tabel er bedoeld wordt. Een constraint aanleggen gaat dan ook niet lukken daarop. En dat is nou net waar databases (o.a.) goed in zijn en handig voor zijn.

"Dynamisch" uitlezen gaat dan dus ook niet. Ik zou of 2 velden maken (1 als FK voor tabel a, 1 voor tabel b), of 2 koppeltabellen maken (afhankelijk of je 1:1 / 1:m / n:m wil).

(Ik moet overigens bekennen wel eens een enkel veld te 'misbruiken' om te verwijzen naar tabel a of b, maar dan kun je aan het 'ID' wél zien wat er bedoeld wordt (productcode 001, 002, 004 of xyz, cde, twk bijv.) en heb ik er verder geen joins of iets dergelijks op nodig).

[ Voor 21% gewijzigd door RobIII op 16-07-2007 13:52 ]

[Hydra]

Verwijderd schreef op maandag 16 juli 2007 @ 13:12:
Bedankt voor je heldere/cynische toon...

Best verhelderend en een trigger om te kijken hoe het op te lossen is als ik geautomatiseerd losse tabellen aanmaak per content type.

Als je graag een thedailywtf vermelding wilt krijgen zou ik het inderdaad zo aanpakken

[Verwijderd]

RobIII schreef op maandag 16 juli 2007 @ 13:46:
[...]
(Ik moet overigens bekennen wel eens een enkel veld te 'misbruiken' om te verwijzen naar tabel a of b, maar dan kun je aan het 'ID' wél zien wat er bedoeld wordt (productcode 001, 002, 004 of xyz, cde, twk bijv.) en heb ik er verder geen joins of iets dergelijks op nodig).

Daar komt de aap uit de mouw...

Ik was denk ik net niet helemaal duidelijk dus probeer de situatie beter uit te schetsen. Het voordeel van het eerste model was dat ik snel nieuwe objecten kan maken en de relatie daartussen ook redelijk goed kan vastleggen.

Nu, dat model blijkt niet te voldoen en de database op de verkeerde manier te gebruiken. Nu moet ik dus op een andere manier mijn doel gaan verwezenlijke: via de webinterface straks nieuwe objecten (nieuws, vacature, locatie) kunnen aanmaken. Zodat ik per installatie voor elkaar krijg dat ik kan aansluiten op de wens van de klant en niet de ene na de andere losse module aan het bewerken ben.



Een klein voorbeeldje ter illustratie. Niet spannend, maar toch wel minimaal wat het systeem straks moet kunnen. Via het systeem moet een nieuwsbericht, een vacature en een locatie gedefinieerd kunnen worden. Waarbij aangegeven moet kunnen worden dat een vacature ook bestaat uit een locatie en een locatie een adres heeft. Het adres zou een standaard 'systeem' tabel kunnen zijn, want de users in het systeem hebben ook een adres. Als je met één query de data wilt ophalen zal de relatie al bekend moeten zijn.

Ik ben bang dat je er dan niet aan ontkomt om toch ergens te vertellen welke relaties er zijn en hoe ze zich verhouden? En die relaties zal je eerst moeten ophalen wil je de data op kunnen gaan halen en kunnen gaan werken met O/R mapping via een gegeneraliseerd object. Of ik wil te veel flexibiliteit creëren?!

[ Voor 11% gewijzigd door Verwijderd op 16-07-2007 14:19 ]

[Creepy]

via de webinterface straks nieuwe objecten (nieuws, vacature, locatie) kunnen aanmaken.

Hier ga je denk ik de mist in. Je wilt dus de gebruiker zelf nieuwe zaken willen laten aanmaken en er een custom relatie tussen leggen. Dat gaat gewoon niet zo makkelijk. Je moet je dan ook afvragen of je dit de gebruiker wilt laten doen. Als je hier een interface voor maakt dan laat je de gebruiker vrij om tussen de gekste zaken relaties te gaan leggen (uberhaupt al moeilijk om daar een fatsoenlijke interface voor te maken om maar niet te spreken over de foutgevoeligheid hiervan).

Als alle verschillende zaken qua inhoud overeenkomen maar bijv. op verschillende plekken zichtbaar moeten zijn maak dan 1 tabel voor al deze zaken en voeg een type kolom toe. Zo kan de gebruiker verschillende type's aanmaken en op verschillende plaatsen laten terugkomen. Nog een tabelletje maken voor alle beschikbare types met hun ID en klaar ben je.

Of ik wil te veel flexibiliteit creëren?!

Ik denk van wel ja.

[ Voor 10% gewijzigd door Creepy op 16-07-2007 14:24 ]

[Verwijderd]

De constructie zoals bij Vacancy <> Location moet zeker wel kunnen (wens van de klant). Of ik dit nu via een webinterface laat regelen, of ik handel die zaken zelf af bij de installatie / configuratie. Dat maakt mij uiteindelijk niet zoveel uit.

Overigens kan je via een webinterface ook allerlei zaken afschermen en dus ook de 'gekste relaties' uitsluiten. Ik zoek ook niet de makkelijkste oplossing; maar voor deze situatie een goede oplossing zonder dat ik elke keer opnieuw verschillende modules moet gaan uitwerken voor elke klant.

[edit 1]

Ik zal dus de relatie tussen location en address bijvoorbeeld moeten laten vervallen; zomaar gaan matchen van User Defined Tables met System Tables lijkt me inderdaad niet slim.

[edit 2]

Want in hoeverre ben ik een database in een database aan het maken als ik het gedeelte uit de eerste oplossing pak (met name de blauwe tabellen: de objectdefinitie) en de manier van data opslaan uit de tweede oplossing pak. Anders zie ik op dit moment geen manier om op generieke wijze te kunnen gaan werken.

[ Voor 33% gewijzigd door Verwijderd op 16-07-2007 14:50 ]

[Creepy]

Hoe vaak gaat het in je systeem gebeuren dat een klant een willekeurig object bijgemaakt wil hebben met een custom relatie? Wilde gok van mijn kant: niet vaak. Alleen die custom relatie is dus het probleem. Maak daar dan ook een stukje maatwerk code voor (of desnoods generiek zodat iedere klant dat weer kan gaan gebruiken).

De tijd die je zelf kwijt bent om deze relatie bij te maken in de code en DB is niet veel. Het gaat je veel meer tijd kosten om de DB in een DB oplossing te maken en overzichtelijk en snel te houden.

[Verwijderd]

Dat is natuurlijk de vraag: hoe vaak gaat zoiets voorkomen en hoe ontwikkel je niet onnodig allerlei intelligentie wat niet gebruikt wordt. Op dit moment hebben we onze e-commerce oplossing (gebaseerd op het eerst aangedragen idee) voor een aantal klanten ingezet die complexe product data wilden presenteren. Zo hebben ze het volgende (vereenvoudigd):

Product A
- snelheid (rpm)
- koppel (Nm)
- vermogen (watt)

Product B
- slag (mm)
- kracht (N)
- snelheid (mm/sec)

Dit zijn drie eigenschappen die elk uit een bereik (min en max waarde) bestaan. Dat is perfect in ons model gezet, we kunnen binnen die waardes zoeken zodat we snel een product A kunnen selecteren die voldoet aan 1200rpm aangezien die van 1000 - 1500 rpm te regelen is. Dit zijn nog maar twee producten die hele andere eigenschappen hebben, maar het kan ook een boek, fiets of wat dan ook zijn wat we definieren. Ook kan er per veld aangegeven moet worden of die multi language is. 1200 is in zowel het Engels, Frans als Nederlands nog steeds 1200. Je hoeft namelijk alleen maar de naam en beschrijving te vertalen. Ook is het mogelijk om producten te groeperen en in meerdere maten en kleuren te presenteren. Nu gaat dit wel meer over e-commerce; maar het blijft content wat te beheren moet blijven en dus ook in dat model kwijt moet.

Als ik met losse tabellen ga werken heb ik een probleem. De min en maxwaarde hebben geen relatie in een platte tabel en kan dus niet generiek opgelost worden: maatwerk. Ik zal getallen dubbel moeten invoeren bij een vertaling of een handmatige intelligentie extra in mn software moeten bouwen die die getallen overneemt.

Ik heb wel het idee, ondanks dat je een database in een database aan het bouwen bent, de mogelijkheden om zaken complexer te generaliseren groter zijn: maar goed: ik sta open voor een verhaal waarbij blijkt dat die complexe generalisatie netter opgelost kan worden: of dat het efficienter is om elke keer maatwerk te leveren.

[RobIII]

Verwijderd schreef op maandag 16 juli 2007 @ 15:31:
Nu gaat dit wel meer over e-commerce; maar het blijft content wat te beheren moet blijven

Je moet wel je termen even op een rijtje zien te krijgen. e-commerce is iets heel anders als een producttabelletje

Verwijderd schreef op maandag 16 juli 2007 @ 15:31:
Als ik met losse tabellen ga werken heb ik een probleem. De min en maxwaarde hebben geen relatie in een platte tabel en kan dus niet generiek opgelost worden: maatwerk. Ik zal getallen dubbel moeten invoeren bij een vertaling of een handmatige intelligentie extra in mn software moeten bouwen die die getallen overneemt.

Dat is IMHO iets wat je in je GUI moet oplossen. Als je niet voor iedere taal die waarde 'dubbel' wil invoeren dan neem je het product over bij het aanmaken van een anderstalige omschrijving inclusief alle waardes behalve de taalspecifieke (dus eigenlijk een 'kopie' van het product). Dat is een hele snelle methode; maar niet erg veilig voor je consistentie.
Je kunt natuurlijk ook een tabel met alleen 'harde cijfers' en gegevens (niet-taalspecifieke data) maken en een tabelletje met vertalingen van (bijv.) omschrijvingen etc.

[Verwijderd]

Elk woord wordt hier gewogen

Je snapt mn punt neem ik aan wel. Vanuit de ervaring binnen e-commerce waar bedrijven hun producten moeten plaatsen zijn we al aangelopen tegen de grote variatie van productpresentatie (wat betrekking heeft op content management).

Ook bij een vacature (hoewel het een mindersterk voorbeeld is) loop je hier tegen aan. De uren en het bedrag hoeven niet vertaald te worden. Wel de functie en de beschrijving van een vacature.

Je kan veel zaken wel in je GUI wel oplossen; maar ergens moet je tegen je systeem vertellen dat die twee kolommen bij elkaar horen. Of dat een bepaalde kolom geen vertaling nodig heeft.

Maar goed: je blijft het probleem houden van het dynamisch definieren en het generiek ophalen. Ergens moet verteld worden wat er aangemaakt is, wat de eigenschappen zijn, wat er vertaald moet worden en welke kolommen een bereik vormen... Of blijf ik eigenwijs in een verkeerde gedachte hangen? En heb ik een foute applicatie ontwikkeld waarbij dit allemaal wel werkt?!?! Of zijn jullie database puristen

[Creepy]

"Fout" is een groot woord. Als het werkt: prima. Maar eerlijk gezegd verwacht ik dat de performance van zoeken in een groot aantal produkten zwaarder is dan nodig. En eerlijk gezegd wil ik de code + querie's voor het zoeken niet onder ogen krijgen.

Als het echt zo dynamisch moet zijn dat de klant een aantal zaken zelf kan aanmaken, toevoegen en verwijderen probeer dan in elk geval alle eigenschappen die hetzelfde zijn (naam, prijs, omschrijving om er maar drie te noemen) in een "vaste" tabel te zetten i.p.v. alles in je "DB in een DB" te definieren. Alles in je "DB in een DB" zetten werkt en is superdynamisch maar niet elke oplossing die werkt is de beste oplossing

Het kan nodig zijn om zo'n oplossing te implementeren, maar als je dit 100% gebruikt dan gebruik je bijna geen enkel sterk punt meer van een (R)DMBS en werk je jezelf eigenlijk alleen maar tegen (ook al lijkt het veel dynamischer).

En nee, zo'n grote purist ben ik nu ook weer niet (ook al lijkt dat misschien nu van wel ).

[ Voor 26% gewijzigd door Creepy op 16-07-2007 16:21 ]

[Verwijderd]

Het geeft logischerwijs meer load. En ben ook van mening dat het belanrijk is een DMBS te gebruiken waarvoor hij is. Ik ga dus eens broeden op een betere oplossing waarbij ik dergelijke zaken zoals we ze nu hebben draaien ook in kan oplossen.

Verder blijf ik geïnteresseerd in andere of bevestigende visie die iets kunnen toevoegen om tot een beter, maar wel flexibel model te komen. Ik ben dan bereid om eventuele vorderingen hier te posten van wat uit mijn grijze massa vloeit...

[RobIII]

Verwijderd schreef op maandag 16 juli 2007 @ 16:25:
Verder blijf ik geïnteresseerd in andere of bevestigende visie die iets kunnen toevoegen om tot een beter, maar wel flexibel model te komen. Ik ben dan bereid om eventuele vorderingen hier te posten van wat uit mijn grijze massa vloeit...

Zoals je in het andere topic ook (meermalen) kunt lezen is het een kwestie van balans vinden tussen 'een db-in-en-db' en een compleet genormaliseerd model. Veel meer zinnigs kun je hier (IMHO) niet over vinden.

[Orphix]

Om die bevestigende en andere visie te zijn: hierbij mijn bijdrage

Kort door de bocht: RobIII heeft helemaal gelijk. Je datamodel die je nu hebt opgesteld deugt simpelweg niet, en naarmate je er meer over gaat nadenken of ermee gaat werken zal het je duidelijk worden. Het is dus inderdaad een klassieke valkuil waarbij mensen vaak een 'slimme' applicatie bouwen om ultiem flexibel te zijn, waarbij je vervolgens genoodzaakt bent alle mogelijkheden van een database server slecht te moeten emuleren om er nuttige resultaten uit te kunnen krijgen.

Dus wat is een oplossing? Ten eerste zeg je dat je aan OOP doet. Dat is heel erg mooi. Hoe zou je het daarin oplossen? Waarschijnlijk wil je dat alle producten een aantal eigenschappen delen (bijvoorbeeld een primary key, naam, categorie, prijs). Dit zou je dan oplossen in een 'base class'. Je andere producten (die nog onbekend zijn!) kan je dan mooi toevoegen als afgeleide classes: nu, of over een jaar wanneer nieuwe product types op de markt komen.

De vraag nu is natuurlijk: hoe vertaal je dit naar een database schema?! Er zijn meerdere manieren om een classe hierarchie weer te geven in een database structuur (zoek maar eens rond in het O/R mapping wereldje), maar een simpele en redelijk performante is om een tabel aan te maken voor je basisclasse, en vervolgens een tabel voor elke afgeleide klasses. Die je via dezelfde primary key met elkaar linkt.
Nu is het een mythe dat een sql schema onveranderbaar is nadat je eenmaal de applicatie uitgerold hebt. Je kan met een aantal simpele SQL statements eenvoudig tabellen toevoegen en kolommen bewerken. Je kan vanuit je applicatie dus on-the-fly je database structuur wijzigen. In jouw geval lijkt me dat zeer wenselijk aangezien je bij e-commerce pakketen geen idee hebt wat voor producten erin komen te staan. Vervolgens moet je ergens meta-data kwijt, zodat je applicatie later weet wat voor tabellen er zijn en wat ze voorstellen. Maar ook meta-data kan je kwijt in de meeste database servers. Of je maakt een metadata tabel aan waar je alles in gooit.

Verdiep je eens in de mogelijkheden die een database server biedt en dan denk ik dat je top e-commerce pakket een groots succes wordt Succes ermee!

[Verwijderd]

Bedankt voor de bevestigende reactie

Alles eens rustig laten bezinken. Druk aan het brainstormen geslagen voor een nieuw databasemodel. Ik kan aardig de flexibiliteit kwijt die ik had binnen het 'verkeerde' model. Ik ben er nog niet klaar mee, maar zie wel mogelijkheden. Enige waar ik nog over twijfel: ik wil mn definities in XML vast gaan leggen. Ik wil namelijk zeggen welke attribute van een object tegen welke validatie regel gehouden moet worden en welke relaties ze hebben met andere tabellen. Ik lees dan mn XML definitie in en ga daarmee verder om de data mee op te halen. Nu doet Propel (O/R mapper voor PHP) iets dergelijk op dezelfde wijze. Het lijkt mij ook iets eenvoudiger dan weer een definitie vastleggen in de database (je bent dan volgens mij weer een db in een db aan het bouwen). Wat is jullie mening/visie hierop?

[RobIII]

Verwijderd schreef op maandag 06 augustus 2007 @ 16:06:
ik wil mn definities in XML vast gaan leggen
<snip>
Het lijkt mij ook iets eenvoudiger dan weer een definitie vastleggen in de database (je bent dan volgens mij weer een db in een db aan het bouwen). Wat is jullie mening/visie hierop?

Dat je nog steeds een db-in-een-db bouwt, maar nu de definitie in XML opslaat Dus ondanks dat je het anders (of op een andere plek) opslaat doe je nog steeds hetzelfde kunstje

[Verwijderd]

He, die opmerking had ik verwacht

Dan moet ik toch nog een andere manier gaan uitbroeden waardoor ik kan aangeven dat een bepaald veld een bepaald formaat moet gaan bevatten... Toevallig een tip of idee?

[edit]

Ik wil in mn interface gewoon automatisch kunnen afvangen dat wanneer iemand volgens het object een emailadres invult, dit ook een emailadres is.

Object
- id
- name

ObjectInstance
- id
- objectid *
- createdate
- lastmodifieddate

NewsObject
- id
- objectinstanceid *
- title
- intro
- description
- writer
- writer_mail

Ik wil dus vastleggen dat wanneer iemand via de backoffice een nieuwsbericht invoert het emailadres van de schrijver correct qua syntax invult. Ook wil ik bij een meertalige backoffice kwijt wat de nederlands, engelse en duiste tekst is van het label wat hoort bij het invoerveld van het emailadres van de schrijver. Ik zie gewoon niet een oplossing. Ik broed me suf...

[ Voor 64% gewijzigd door Verwijderd op 06-08-2007 16:42 ]

[RobIII]

Verwijderd schreef op maandag 06 augustus 2007 @ 16:18:
Toevallig een tip of idee?

Ja: lees dit topic nog eens door
DDL. Daarna je query's dynamisch samenstellen et voila: een 'dynamische database'

offtopic:
'submitiondate' lijkt me submissiondate te moeten zijn, maar wat dacht je van 'createdate', 'lastmodifieddate' etc?

En ik neem aan dat "writer" in je NewsObject table een FK is? Zo ja, waarom dan writer_mail opnemen in de NewsObject table? En zo nee, waarom niet?

[ Voor 45% gewijzigd door RobIII op 06-08-2007 16:32 ]

[Verwijderd]

offtopic:
Typo's aangepast...

Het is maar een voorbeeld. Normalite zou je idd kiezen voor een FK naar een tabel met users/writers. Het gaat even om het principe dat ik aan een attribute een validatie regel kan hangen, en meerdere vertalingen voor het label van write_mail. Ook aangeven of een veld verplicht is of niet, is niet mogelijk met deze opzet.

Op het moment dat er een product ingevoerd gaat worden zou een productnummer/artikelcode verplicht moeten zijn, het intro van een News bericht zou in principe weer niet verplicht zijn. O ja, Not NULL is natuurlijk te gebruiken. Ik ben opzich wel voldoende op de hoogte van DDL, en was al wel van plan om dynamische tabellen te gaan creëren en relaties te gaan leggen. Gebruik nu MySQL i.c.m. met de innoDB engine. Doctrine heeft nogal moeite om daar relaties e.d. uit te halen. Zeg maar gerust dat dat helemaal niet lukt. Maar das een ander probleem...

[RobIII]

Je lijkt het probleem maar niet te snappen (NOFI hoor ); met 'generieke' tabellen waar je vanalles en nog wat door elkaar in frot gaat het geheid vroeg of laat mis. De validatie dien je door je GUI te laten doen, de DB doet enkel het consistent houden van je data (dus een DB hoort geen email adres te controleren, maar wel FK constraints af te dwingen etc).

De 'dynamische' velden zul je echter met DDL of dergelijke oplossingen (SQLDMO etc.) moeten aanpakken. Ga je (op welke manier dan ook) een "dynamische database" maken waar je allerlei 'generieke tabellen' en 'velden' in gebruikt dan ga je over een jaar mij weer horen in je achterhoofd als je de wallen onder je ogen hebt van het debuggen "Ik zei nog zo..." *echo*

Er is niet mis met her-of-der een veldje een beetje 'misbruiken'; althans...zolang je niet puristisch bent. Maar ga je je hele database baseren op een db-in-een-db dan gaat het dus hoe dan ook mis vroeger of later.

[ Voor 13% gewijzigd door RobIII op 06-08-2007 18:01 ]

[Verwijderd]

Misschien begrijp ik het inderdaad niet...

Voorzover optie 1: je werkt met een tabel waarbinnen kolommen toegevoegd en aangepast worden. Ik wil gebruik maken van de objecten News, Vacancy en Article. News maakt gebruik van de kolommen title, subtitle, intro, description. Vacancy maakt gebruik van title, salary, duration en description. Article maakt gebruik van title, keywords en description. Kom ik op een tabel uit met de volgende kolommen: title, subtitle, intro, description, keywords, salary en duration. Maak ik een nieuw object aan kan ik gebruik maken van de bestaande opties, anders maak ik één of meerdere kolommen aan. Probleemstelling: welke kolommen horen bij welk object. Dat kan ik hard coded in mn class zetten, of ik gebruik een configuratie file waar dit in staat (db-in-db verhaal?!?!?)

Optie twee is de eerder geschets opstelling waarbij ik gebruik maak van een soort parent tabel ObjectInstance met table children als News, Vacancy en Article. Maar dat zal te veel problemen opleveren in de toekomst omdat je met dynamische tabellen gaat werken.

Het lijkt erop dat ik niet de flexibiliteit kan inbouwen die ik voor ogen heb... Mn database kan ik toch ´standaard houden´ en mn software slim maken? Ik snap ook wel dat mijn GUI de controle moet doen. Maar iemand/iets/xml moet vertellen dat het betreffende ding een emailadres moet zijn (tenzij ik alles hardcoded in klop, maar dan ben ik mn flexibele inrichting kwijt). Zaken die ik kwijt moet zijn:

- bereiken
- gebruik maken van een voorgedefinieerde set van keuzes voor een attribute (FK)
- relaties tussen bijvoorbeeld News en Article (FK)
- meertaligheid van veld labels

Wat is jullie advies (dan wel in bewoording die ik begrijp )? Ik ben dan wel weer eigenwijs genoeg om een middenweg op te zoeken . We hebben een dergelijk model (zoals beschreven in de TS) soepel draaien en ben ik wel van mening dat er her en der wat haken en ogen aan zitten...

[Not Pingu]

Wat je voorstelt is in een e-commerce omgeving wel heel handig om bijv. per productsoort andere data te kunnen opgeven (bijv. een harde schijf heeft eigenschappen als opslaggroote, RPM,... en een TFT scherm heeft kijkhoek, contrast, resolutie, etc.).

Alleen is het kwa performance en bruikbaarheid van de database beter als je die tabellen gewoon dynamisch genereert (dus met CREATE TABLE statements) en je content-item querying doet mbv. dynamische SQL.
Zo voorkom je dat je zelf binnen de database weer een extra laagje logica stopt. Dat is een fout die je veel gemaakt ziet worden omdat developers zich over het algemeen fijn voelen bij het queryen van tabelletjes, maar niet meer dan dat.

Eventueel kun je twee tabellen aanhouden: een met verwijzingen naar je content items met wat standaard velden (titel, startdatum, einddatum, itemtype) en dan per itemtype een aparte tabel met je custom properties.

Was dit ook wat RobIII en anderen in gedachten hadden?

[Verwijderd]

Misschien goed (we zitten ten slotten in Software Architecture) om het beeld wat ik voor ogen heb wat duidelijker uit te schetsen. Dan kunnen we van alle kanten wat concreter zijn met wat we bedoelen en hoe het wel of niet moet.

Het idee, om de beoogde flexibiliteit te realiseren, is om dynamische tabellen aan te maken voor elk soort item wat ik wil gebruiken. Zo kan ik, zoals Not Pingu aangeeft, een harde schijf en een TFT scherm in mijn systeem op de juiste manier kwijt.

Een zeer vereenvoudigd schema heb ik hieronder gezet zodat we weten waar we over praten:



Ik ga dus uit van een Object en een ObjectInstance tabel. De items die ik dus zelf wil definieren zoals in dit voorbeeld News en Article hebben hun eigen specifieke eigenschappen. De data kan ik dus nu op een correcte wijze opslaan en consistent houden: daar is dan ook de database voor...

Om mij applicatie/gui correct te laten werken moet het e.e.a. intelligent worden ingericht. Op basis van de definitie wil ik op het moment dat je een nieuw nieuwsbericht wilt toevoegen ook mijn formulier voor de invoer daarvan aanpassen. Dat is in principe uit te lezen uit de database. Maar dit is beperkt. Stel ik wil mn backend meertalig maken, dan wil ik ook het label 'titel' kunnen vertalen naar 'title' of een andere taal. Dat moet dus ergens vast gelegd worden. Aanvullende data voor een kolom binnen een tabel. Ik zou daar XML voor kunnen gebruiken om mn GUI beter te laten functioneren. Een soort van aanvullende beschrijving op mn object. Hierin zie ik niet dat dit nu db in db is. Mn data sla ik netjes op en gebruik extra mogelijkheden via xml om wat zaken af te vangen. Als ik als kolomtype gebruik maak van TEXT, moet ik een textarea tonen of een WYSIWYG renderen?

Is het mogelijk om concreet aan te geven wat hier fout aan zou zijn? Ik hoop dat ik in ieder geval wat duidelijker ben dan een paar berichten geleden...

[Verwijderd]

Even een kickje, ben toch benieuwd naar reacties op dit iets beter uitgeschetste idee...

[Orphix]

Ik denk dat je heel aardig op de goede weg bent. Maar je zit nog erg op het randje van dingen te generiek aan willen pakken. Je moet oppassen dat je code niet enkel met hele generieke objecten overweg kan gaan, en je vervolgens alle logica/opmaak/businessrules/etc in je meta-data gaat stoppen. In jouw geval je XML bestand. Immers ben je dan nog steeds aan het programmeren, maar dan is het niet in je favoriete programmeertaal, maar in XML.

Om het duidelijker te maken. Stel dat jouw applicatie geen weet heeft van het bestaan van Article of News. Het kan deze objecten dus enkel heel generiek behandelen, wat erop neerkomt dat de code de modificatiedatum en Id kan verwerken en weergeven. Nou zal je uiteindelijk applicatie veel meer velden willen weergeven, wellicht op verschillende manieren en wat if-then-else logica erdoorheen. Waar laat je dit kwijt? In je XML bestand? En wie gaat dat beheren? De onwetende klant die een e-commerce pakket koopt? Alles via een web-interface?

Het is dan al snel eenvoudiger om met 'modules' te werken. Dus programmatuur die weet hoe het overweg moet met objecten van Article of objecten van News. De functionaliteit die je uiteindelijk wilt moet hoe dan ook ergens worden vastgelegd. Dit kan efficient en eenvoudig via code dat hier voor gemaakt is (php, asp.net), of via verschillende tussenlagen met eigen meta-data bestanden. Wat het uiteindelijk veel complexer maakt.

Waar ik dus voor pleit is dat je concreet een aantal hoofdtypes maakt, bijvoorbeeld 'computer', 'monitor', 'samengesteld systeem', 'kortingsbon', etc. Hiervoor schrijf je dus al concreet in je programmatuur hoe hiermee moet worden omgegaan. En vervolgens kan de klant daar wel velden aan toevoegen, maar slechts beperkt uitbreiden! Je moet daar realistisch in blijven, en ik denk ook dat enorme flexibiliteit geen eis is.

[Verwijderd]

Mooi dat we langzaam de goeie weg op gaan!

Mijn applicatie weet eigenlijk altijd welke objecten aanwezig zijn (Table Object) en welke velden daarbij horen zijn af te leiden uit 'grijze' tabellen uit mijn voorbeeld. Het XML bestand wat voornamelijk voor de GUI gebruikt wordt, zal beheerst worden via een webinterface om op die manier fouten te minimaliseren / uit te sluiten.

Ik snap je punt en ben het met je eens om zoveel mogelijk in php / asp.net uit te werken in code en daarin vast te leggen hoe objecten als News en Article behandeld moeten worden. Ik wil alleen niet bij elke installatie weer wat nieuws moeten programmeren als het om zulk soort 'eenvoudige' objecten gaat. Dat is dom werk, en uiteindelijk heb je een berg objecten die ongeveer allemaal hetzelfde doen (je kan natuurlijk in OOP veel overerven, maar toch, elke keer hetzelfde kunstje is wat saai). De flexibiliteit is ook meer vanuit mijn oogpunt als verkopende partij. Het kost me uiteindelijk ook minder tijd om een applicatie in te richten als ik alleen een configuratie file hoef samen te stellen met als resultaat een sluitende oplossing.

[Not Pingu]

Orphix schreef op vrijdag 10 augustus 2007 @ 00:44:
Om het duidelijker te maken. Stel dat jouw applicatie geen weet heeft van het bestaan van Article of News. Het kan deze objecten dus enkel heel generiek behandelen, wat erop neerkomt dat de code de modificatiedatum en Id kan verwerken en weergeven. Nou zal je uiteindelijk applicatie veel meer velden willen weergeven, wellicht op verschillende manieren en wat if-then-else logica erdoorheen. Waar laat je dit kwijt? In je XML bestand? En wie gaat dat beheren? De onwetende klant die een e-commerce pakket koopt? Alles via een web-interface?

Veel O/R mappers hebben hier wel een voorziening voor. Icm. (N)Hibernate zou TS bijv. mappingfiles kunnen genereren. Deze zullen niet al te ingewikkeld zijn aangezien de structuur altijd hetzelfde is: een aantal properties met een foreign key-relatie naar ObjectInstance.

[mOrPhie]

Waarom kan een ObjectInstance meerdere artikelen hebben? Wat is dan precies een ObjectInstance? En waarom kan een Object meerdere ObjectInstances hebben? Wat is dan precies een Object?

Als je een data-model maakt, dan moet je je richten op de platte data waar nog allerlei redundantie in zit. Vanaf daar verbeter je het model door te normaliseren waar je dubbele data verwacht. Het Object/ObjectInstance principe wat je hier wilt gebruiken snap ik in die context niet. Welke attributen van een artikel normaliseer je in ObjectInstance en vervolgens Object?

Wat jij volgens mij wilt is een generieke interface voor objecten op je website (met specialisaties naar artikelen, nieuws, enz) en de implementatie een renderstrategie laten kiezen (of krijgen middels dependency injection / IOC) op basis van de specialisatie die je wilt renderen. Dat doe je dus niet in je datamodel, maar in je klassemodel.

Je intentie is dus goed, maar bedenk dat je in een datamodel normaliseert en in je klassemodel ontwerpt. Dat is ook de reden waarom je vaker begint met een klassemodel en daar vanuit de tabel-kandidaten kiest.

[Verwijderd]

Vanuit de eerder gedane (minder omvangrijke) applicaties is de gewoonte ontstaan om te beginnen met het ERD. Vandaar dat onderstaande vragen vanuit dat perspectief beantwoord zijn, en niet vanuit het ontwerp van een klassendiagram. Nu ben ik ook bezig om het systeem middels UML meer in kaart te brengen, dus wellicht dat dit mij het e.e.a. aan inzicht gaat verschaffen.

Waarom kan een ObjectInstance meerdere artikelen hebben?

Dat is in dit voorbeeld inderdaad niet duidelijk. Heeft te maken met de meertaligheid. Dit is een subtractie vanuit mijn iets uitgebreidere model.

Wat is dan precies een ObjectInstance?

Bevat de basisgegevens. Deze Instance wordt dan dus uitgebreidt met specifieke eigenschappen als een title, description e.d. van bijvoorbeeld een News item.

En waarom kan een Object meerdere ObjectInstances hebben?

Een instance is een item. Een object is de naam van de class om het zo maar te zeggen.

Wat is dan precies een Object?

Voor mij alleen een verzamelnaam. News, Article e.d.


Ik wil inderdaad een generieke interface voor met name tekstuele data. Ik zal me wellicht meer moeten richten op het klassendiagram. Toch lastig je werkwijze aanpassen. Maar als dat resulteert in betere en stabiler geheel ben ik daar niet te beroerd voor. Ben van origine ook geen programmeur / software architecteur dus sta open voor veel tips.

[mOrPhie]

Verwijderd schreef op vrijdag 10 augustus 2007 @ 09:49:
Waarom kan een ObjectInstance meerdere artikelen hebben?
Dat is in dit voorbeeld inderdaad niet duidelijk. Heeft te maken met de meertaligheid. Dit is een subtractie vanuit mijn iets uitgebreidere model.

Hoe breng je in dat model meertaligheid in dan? Ik zie niets van een language attribuut oid. Hoe zie jij dat?

En waarom kan een Object meerdere ObjectInstances hebben?

Een instance is een item. Een object is de naam van de class om het zo maar te zeggen.

Mjah, zoals gezegd zie ik niet waarom de naam van een class een kandidaat tabel is. Als het voor meertaligheid is, los dan meertaligheid op, maar niet op deze cryptische manier.

Wat is dan precies een Object?

Voor mij alleen een verzamelnaam. News, Article e.d.

Dat hoef je toch niet bij te houden? Het feit dat het in een "Artikel"-tabel staat is toch genoeg?

Ik wil inderdaad een generieke interface voor met name tekstuele data. Ik zal me wellicht meer moeten richten op het klassendiagram. Toch lastig je werkwijze aanpassen. Maar als dat resulteert in betere en stabiler geheel ben ik daar niet te beroerd voor. Ben van origine ook geen programmeur / software architecteur dus sta open voor veel tips.

Zoals hierboven al gezegd: we hebben allemaal de fout gemaakt dingen generiek willen oplossen, maar vraag je wel af waarom je zoiets wilt en wat de waarde ervan is.

Ik zou me als ik jou was even in lezen in basisprincipes van Object Orientatie en vervolgens hoe je uit een klassenmodel een datamodel extraheert. Dat voorkomt een hoop beginnersfouten.

[Not Pingu]

mOrPhie schreef op vrijdag 10 augustus 2007 @ 10:12:

Zoals hierboven al gezegd: we hebben allemaal de fout gemaakt dingen generiek willen oplossen, maar vraag je wel af waarom je zoiets wilt en wat de waarde ervan is.

Dat lijkt me hier wel duidelijk toch? Het is imho nogal beperkend om voor het aanmaken van bijv. productdefinities weer een developer erbij te moeten halen.
MS Commerce Server kent eenzelfde systeem met custom properties voor content items. Hoe ze dat onder de motorkap oplossen weet ik natuurlijk niet, maar het is wel een vrij essentieel onderdeel van een e-commerce omgeving (wat de TS wil maken).

[mOrPhie]

Not Pingu schreef op vrijdag 10 augustus 2007 @ 11:45:
[...]


Dat lijkt me hier wel duidelijk toch? Het is imho nogal beperkend om voor het aanmaken van bijv. productdefinities weer een developer erbij te moeten halen.

Oh zeker hoor, maar een Object-tabel hebben en vervolgens de tabellen "Article" en "News" maken helpt daar niet bij. Dat is schijn-generiek.

Ik ben ook niet fan van de database in database methodiek, maar dat laatste voorbeeld klopt qua generieke oplossing ook niet.

[Not Pingu]

Er zit idd een tabel teveel in en de een-op-veel relaties moeten een-op-een zijn. Maar het idee lijkt me toch redelijk correct en in overeenstemming met de suggesties uit de eerste 30 posts.

[Vedett.]

Oh zeker hoor, maar een Object-tabel hebben en vervolgens de tabellen "Article" en "News" maken helpt daar niet bij. Dat is schijn-generiek.

Dat is anders wel de manier waar je zelf op aan stuurt, althans 1 kans op 3 dat het zo is. Je stelt voor dat de TS eens een boek moet lezen om te kijken hoe je een klassen model omzet in een relationeel model, daar zul je daar dus maar 3 oplossingen.

Stel een klassendiagram met voertuig als basisklassen, auto en boot als subclassen.

1. Alles in 1 master tabel. voertuig krijgt dan de velden van auto en boot (1 tabel)
2. Alles in aparte tabellen. auto en boot krijgen dan velden van voertuig (2 tabellen)
3. Aparte tabel en master tabel. (3 tabellen)

Het voorbeeld is dus echt wel OK.
Ik denk dat de TS te veel hooi op zijn vork neemt en eens moet kijken naar kant en klare producten met eventueel wat custom development.
Sharepoint, MS Dynamics, MS Commerce Server (ja ik weet het, ben nogal een MS programmeur)

[Orphix]

Not Pingu schreef op vrijdag 10 augustus 2007 @ 09:16:
Veel O/R mappers hebben hier wel een voorziening voor. Icm. (N)Hibernate zou TS bijv. mappingfiles kunnen genereren. Deze zullen niet al te ingewikkeld zijn aangezien de structuur altijd hetzelfde is: een aantal properties met een foreign key-relatie naar ObjectInstance.

Als de topicstarter er heel erg in thuis is zou hij ook on-the-fly code kunnen genereren en die in de App_Code directory plaatsen (wordt automatisch gecompileerd). Is wel stoere oplossing eigenlijk nu ik erover nadenk

Ik denk dat we het er allemaal over eens zijn dat de soorten producten uitbreidbaar moet zijn. Immers kan je nooit op voorhand vastleggen wat voor producten de klant er in wil hebben. Dan is de tweede vraag: wat wil je voor, en wat wil je na deployment vastleggen. Mij lijkt het dan logisch om voor deployment alle benodigde functionaliteit (businessrules, UI logica, zoekfuncties, etc) te coden. En na deployment enkel 'attributen' aan te maken. Dit kan prima in de database server worden opgeslagen in de vorm van (extended) properties. Deze attributen geven aan op welke manier code met de data om moet gaan. Bijvoorbeeld welke velden zoekbaar zijn, en welke niet. Of welk veld een kleur voorstelt en dus een color-picker interface krijgt. Maar je wilt niet aangeven hoe zo'n color-picker dan gemaakt wordt. Dat codeer je vooraf al.

Hoe je de meta-data uit de database server trekt en dat run-time omzet in de gewenste functionaliteit is het tweede gedeelte. Daar zijn meerdere oplossingen voor te bedenken. Hibernate, stored procedures, code genereren, caching, hashtables, etc.

Sooterd, ik denk dat je niet enkel moet kijken naar de datastructuur, maar ook hoe je deze gegevens wilt gebruiken in je site. Hoe gaat je zoekfunctie ermee om, categorieen overzicht, ordertabellen, factureren, aanbiedingen, ui interface elementen, etc. Dan wordt vanzelf duidelijk aan welke interfaces je data en meta-data moet voldoen.

[Vedett.]

Immers kan je nooit op voorhand vastleggen wat voor producten de klant er in wil hebben. Dan is de tweede vraag: wat wil je voor, en wat wil je na deployment vastleggen. Mij lijkt het dan logisch om voor deployment alle benodigde functionaliteit (businessrules, UI logica, zoekfuncties, etc) te coden

Hoe weet je in godsnaam wat je businessrules zijn als je ten eerste al niet weet wat voor content er komt, en ten tweede niet weet wat voor klant dit gaat gebruiken. Elke content is anders en zeker elke klant.

[mOrPhie]

Vedett. schreef op vrijdag 10 augustus 2007 @ 13:13:
[...]


Dat is anders wel de manier waar je zelf op aan stuurt, althans 1 kans op 3 dat het zo is. Je stelt voor dat de TS eens een boek moet lezen om te kijken hoe je een klassen model omzet in een relationeel model, daar zul je daar dus maar 3 oplossingen.

Ik stuur aan op een oplossing waar ik het zelf niet mee eens ben? Sorry, maar we zijn hier met een normale discussie bezig. Ik zou het op prijs stellen als je het even bij mijn feitelijke bewoordingen houdt.

---

Het voorbeeld is geenzins OK. Het idee is goed, de uitvoering niet. Deze implementatie kent een vreemde vorm van normalisatie, die geen generiek voordeel geeft. Zeg nu zelf. Objectnamen (Article, News) als rijen in een database waarvan die objectnamen zelf als tabels gedefinieerd staan? Dat komt mij als enorm vreemd over en zeker niet als de generieke oplossing waar de TS naar zoekt.

Het proces heet overigens gewoon normaliseren. Daar zijn hele boeken over geschreven en dat gaat. Het makkelijkste is gewoon straight-forward te normaliseren: http://nl.wikipedia.org/wiki/Normaalvorm

Ik kraak de TS daar niet mee af, aangezien hij duidelijk lerende is, maar ik ga niet een kant en klare oplossing neerzetten. Daarvoor heb ik simpelweg de tijd niet.

Ik denk dat de TS te veel hooi op zijn vork neemt en eens moet kijken naar kant en klare producten met eventueel wat custom development.
Sharepoint, MS Dynamics, MS Commerce Server (ja ik weet het, ben nogal een MS programmeur)

Daar ben ik het nu eens helemaal mee eens.

[ Voor 3% gewijzigd door mOrPhie op 10-08-2007 14:13 ]

[Orphix]

Vedett. schreef op vrijdag 10 augustus 2007 @ 14:03:
Hoe weet je in godsnaam wat je businessrules zijn als je ten eerste al niet weet wat voor content er komt, en ten tweede niet weet wat voor klant dit gaat gebruiken. Elke content is anders en zeker elke klant.

Ben ik helemaal met je eens. Daarom denk ik ook dat het zeer lastig is om dit na deployment nog flexibel te houden. Met enkel het concept 'object' of 'salesitem' is het lastig dit door te voeren. Je zal dus al een stukje specifieker moeten werken. Bijvoorbeeld concepten als 'discountitem' (voor items met staffelkortingen) of 'FastSalesItem' voor producten waarvan een snelle doorlooptijd moet worden gerealiseerd en de prijs lager wordt naarmate er minder producten van worden gekocht. Dit zijn lastige businessrules om achteraf maar ff toe te voegen via een XML bestand. Dit is een essentieel onderdeel van je programmatuur. Oftewel je komt met 'predefined' businessrules die eventueel wel te parametriseren zijn (via de opgestelde attributen), maar waarvan het concept vooraf bekend is. Dat bedoelde ik met coderen voor deployment.

Ik heb geen ervaring met e-commerce systemen, maar ik vermoed dat er in de praktijk twee soorten klanten zijn. 1) De klanten die een beperkt aantal verschillende items verkopen met simpele administratie en businessrules. en 2) De klanten die door middel van een geadvanceerde e-commerce site dat in hun voordeel gebruiken. Bijvoorbeeld een Dell. Maar de vraag is zeer of die voor een standaard pakketje gaan, aangezien veel dan toch maatwerk wordt. Ook hier geldt voor de TS: weet je wel zeker dat de flexibiliteit gewenst is?! Op welke markt richt je je?

[Verwijderd]

Zo, een klein weekendje weggeweest en de discussie gaat door! Positief. Ik ga mn best doen om alles samenvattend te beantwoorden.

Een aantal opmerkingen lees ik over het database model (losstaand van het feit dat ik bij mijn applicatie ontwerp niet mee moet beginnen.)

De 1:N relatie tussen ObjecteInstance en Article hoort in principe ook een 1:1 relatie te zijn. Alleen op het moment dat ik meertalig ga werken wil ik per taal een kopie opslaan en komt de 1:N relatie te voorschijn. Ik had een kopie gemaakt uit mijn totale model gemaakt en vergeten die relatie voor het voorbeeld 1:1 te maken. De table Object is inderdaad niet perse nodig. Redenerend vanuit de table Article of News kom je ook uit op wat voor soort content het is.



De opdracht is wellicht wat te heftig voor mij, maar ik ga graag tot het randje, of er wat overheen. Ik ben niet anders van mijzelf gewend .

Of de flexibiliteit nu echt in de applicatie gebouwd moet worden? Ik ben van mening dat dat noodzakelijk is. Het is te kostbaar om voor elke implementatie veel uren extra te programmeren. Nu kan ik de investering (die hoger is bij een generieke oplossing, dan bij een standaard oplossing) af schrijven over meerdere implementatie en zit ik niet elke keer (of in ieder geval vaak) met extra maatwerk. Voor mij voldoende reden om de haalbaarheid te onderzoeken van een generieke oplossing (tot op een bepaald niveau) en hoe dit te realiseren. De basis principes voor OOP zijn mij bekend. Dus ben daar niet helemaal een nono in.

De markt waar ik me op richt is MKB en met name het midden bedrijf. Je merkt vandaag de dag dat bedrijven meer willen kunnen. De vraag van deze klanten is niet in een standaard oplossing te gieten. De een verkoopt kleding, de ander wil reizen aanbieden en de derde weer verschillende soorten artikelen. Het is te breed om dat te generaliseren. Daarnaast willen wij een passende oplossing creëren voor onze klanten, een halfbakken oplossing schiet niemand wat op. Vandaar deze discussie en mijn oriëntatie.

Ik heb al bijzonder veel nuttige reacties gekregen. Sommige twijfelen nogal aan mijn vermogen. Kan ik me voorstellen. Ik heb een telematica achtergrond en moet veel zelf onderzoeken en uitvogelen. Dus niet alles zal volgens de boeken gaan. Heb wel een creatief denk vermogen, dus ben van mening dat ik hierin uiteindelijk ook een oplossing in kan verzinnen.

Zoals Orphix aangeeft in zijn post moeten zoveel mogelijk zaken voor deployment gerealiseerd worden. Na deployment enkel alleen het toevoegen van objecten met de bijbehorende attributes. Het enige wat je na deployment vast moet leggen zijn verschillende zaken die gekoppeld zijn aan de attributes:

- Verplicht ja /nee (vast te leggen in sql)
- Validatie en format
- Eventuele tool om input te vereenvoudigen (kalender, colorpicker, etc…)
- Labels in meertalen (naam, name, nom, Name, etc…)

De vraag dus: waar leg je deze gegevens vast die je na deployment wil definiëren. Een deel kan via sql opgelost worden, een ander deel gewoon niet. Die zou ik persoonlijk dus gewoon in een xml file (oid) vast willen leggen. Dat lijkt me de eenvoudigste manier van werken. Een soort van configuratie file voor een object. Lijkt me losstaan van het db-in-db verhaal?!

Zaken met betrekking tot kortingen, facturen, orders e.d. ligt voor deployment vast, daar zijn vaste regels binnen het pakket in te bakken. Wat eventueel schaalbaar moet zijn is een SOAP connectie of een export CSV voor een administratie pakket e.d. Maar goed, laatst genoemd is niet relevant voor deze discussie, die gaat over het behandelen van data.

Ik ben ook niet opzoek naar een kant en klare oplossing. Dan is voor mij het leukste werk gedaan. En dat is toch het architecten werk. Code kloppen vind ik dan ook niet spannend! Ik ben wel opzoek naar kritische notes en sturende opmerkingen. Daar heb ik er al best wel wat van gekregen en wil ik er graag nog meer.

[Vedett.]

Ten eerste twijfel ik niet aan jouw kunnen. Ik twijfel meer aan het kunnen van je database, de applicatie die je gaat maken. En ten tweede zie ik ook dat je bereid bent om tot op het randje te gaan. Maar de ravijn waar je voor staat is wel heel diep, en er liggen al redelijk wat lijken in.

Je probeert je model veel te abstract in een RDBMS (ja, de eerste r staan voor Relationeel) systeem te steken. Ik zie eerder een oplossing met dynamische SQL. Je kan misschien gebruik maken van xsd om een schema te definieren. Met dat schema kan je dan tabellen, klassen, GUI, queries genereren. Je kan xsd's met elkaar linken om relaties te creëren (leverancier -- product). Het enige waar ik nog niet helemaal uit ben is de meertaligheid.

Maar nogmaals, kijk eens hoe anderen het hebben gedaan. Of kijk eens naar MOSS (niet WSS), die heeft alles aan boord wat je wilt, al dan niet via een of andere webpart die je zelf hebt geschreven.

[mOrPhie]

2 dingetjes:

• Op zich maakt het nu wel sense waarom je objectinstance en article/news van elkaar schijdt. Op deze manier klopt het inderdaad. Enige opmerking die ik daar nog bij heb is: Waarom moet article nu een ID hebben? ObjectInstanceID + LanguageID is toch al een sleutel? In een query zal je ook nooit direct een bepaald articleid nodig hebben. Altijd een ObjectInstanceID + LanguageID.

• Persoonlijk zou ik me bezinnen over de typen objecten die je CMS moet ondersteunen, waarbij je eventueel nog een goeie methode bedenkt om extra velden aan een object te hangen. Hoe dan ook, het tabel "Object" zou bij mij verdwijnen en "ObjectInstance" zou bij mij "Document" gaan heten. Zo is het duidelijk en straight-forward. Het is dan: je hebt een document. Een document kan een article of een news-item zijn in een bepaalde taal.

[Verwijderd]

Aan het DB model is idd nog wel het e.e.a. te schaven en te vereenvoudigen. Dit alles komt uit een eerste schets.

Ik ben me nu aan het inlezen op het maken van class diagrammen. Wellicht gaat mij dit ook nog wat licht geven over de te realiseren oplossing

Grootste openstaande vraag op dit moment is nog waar ik metadata kwijt moet. Een xsd is volgens mij te beperkt en alleen een validatie middel om je xml valid te houden voor zover mijn kennis rijkt. Zou ik een eigen XML file kunnen gebruiken waar aanvullende metadata in staat? Voor zover ik kan zien heb ik het idee dat dit het snelst en eenvoudigst voor mij gaat werken. De data die daarin staat is uiteindelijk alleen maar voor mijn UI en heeft in principe niets aan beschrijvende data over de structuur en consitentie van mijn data in db in zich...

[EfBe]

Het is wellicht verstandig eerst eens boven water te halen wat het verschil is tussen een entity definitie en een entity instance. Je bent nu beide aan het samenknijpen in 1 relationeel model met een gedrocht als gevolg:
- Waarom is language een entity en geen value?
- WTF is objectinstance ? Een row in die table, is dat dan een objectinstanceINSTANCE ? zie je hoe de handel wringt?
- een 1:1 relatie die niet optioneel is is onnodig: entities samennemen.

Ik zou zeggen, lees eens Nijssen en Halpin's boeken over datamodellering, (en dat zouden meer mensen moeten doen), dan kom je er wellicht achter dat wat je probeert leuk is voor de buhne, maar voor de rest niet ergens toe leidt.

[Verwijderd]

Voor sommige is mijn naamgeving niet helemaal gelukkig gekozen. Op zich goed om ook hierbij stil te staan, maar staat wat mij betreft enigzins buiten de discussie. Het verschil tussen een entity en een instance ken ik, er is al eerder gezegd dat ik te veel vanuit het classen diagram gedachte mn kleine voorbeeldje geschetst heb, dus vandaar ook de naamgeving hierin.

Waarom language geen value is? Deze opzet door er een entity van te maken heeft naar mijn idee meer controle inzich. Wat als er een tal bij komt of af gaat? Met een eenvoudige query is dit dan op te lossen. Ik heb verder nog niet uitgebreid nagedacht over de verschillende mogelijkheden om multi language in te bouwen.

ObjectInstance is de naam die in het class diagram presentstaat voor een instance van News of Article.

De 1:1 relatie is wel nodig aangezien er aan de table 'ObjecteInstance' (of hoe die ook mag gaan heten) meerdere 1:1 relaties heeft. Ik kan natuurlijk alles samennemen en een hele brede tabel nemen. En dan kom ik weer terug bij mijn vorige post met de vraag: wat leg ik in mijn object configuratie file vast? Welke kolommen hij mag gebruiken?

De huidige opzet is aardig te optimaliseren en kan je zonder gekke query's leegtrekken. En dan hebben we nog index's en caching.