CRM data efficient opslaan

[Anoniem: 130503]

Ik breek al een tijdje mijn hoofd over het opslaan van CRM (Customer Relationship Management) gegevens op een generieke manier. Met een systeem moeten verschillende partijen hun eigen CRM velden kunnen aanmaken, bewerken, verwijderen.

De vraag is; hoe sla je dit soort gegevens efficient op, zonder consessies te doen aan performance. Welke taal gebruikt wordt voor de implementatie maakt me op dit moment niet zoveel uit, en ook de DBMS is niet zo van belang. Ik ben meer geinteresseerd in de concepten.

Er zijn verschillende mogelijkheden die ik overwogen heb;

1.) fysieke tabel bijhouden per gebruiker, waarin ieder CRM veld een attribuut is van de tabel. Dit zorgt voor snelle performance, maar qua onderhoud lijkt het me niet echt verstandig; wat zijn de consequenties voor het verwijderen van kolommen, of het toevoegen; hoe snel gaat dat?

2.) Opslaan van velden en die koppelen aan instanties van velden die bij een enkele CRM kaart (gegevens van een persoon met daarin de attributen die aangemaakt zijn.) horen;

code:

table attribute
---------------------
pk_attribute_id
at_name

table crmcard
---------------------
pk_crmcard_id
... some general metadata about the card

table crmcard_data
---------------------
fk_attribute_id
fk_crmcard_id
da_value

Dit heeft echter een nadeel; elk CRM veld wordt opgeslagen onder eenzelfde type, terwijl er in de praktijk verschillende types zijn; leeftijd moet altijd een getal zijn, een regelige invoer ga je niet in een longtext veld gooien, een prijs is een float, etc.

Ik vraag me af of mensen hier ideeen hebben hoe je CRM gegevens op een generieke manier op kan slaan. Wat discussie met betrekking tot dit onderwerp is misschien interessant, dus schiet mij maar lek.

[The Eagle]

Ga eens op zoek naar het begrip "varianten", dan vind je denk ik wel wat je zoekt

[Anoniem: 130503]

helpt niet veel

zou je iets nauwkeuriger kunnen zijn?

/edit: of doel je op variant datatypes?

[ Voor 17% gewijzigd door Anoniem: 130503 op 04-04-2006 19:05 ]

[Varienaja]

Anoniem: 130503 schreef op dinsdag 04 april 2006 @ 16:31:
leeftijd moet altijd een getal zijn

Je leeftijd is het verschil in jaren tussen nu en je geboortedatum. Sla nooit een veld leeftijd op, maar alleen geboortedatum. Dat is voldoende.

Voor het beste systeem moet je gewoon tabellen uitnormaliseren. Maar als je generiek en efficient wilt zijn dan is je oplossing met die attribuut-tabel wel OK. Persoonlijk zou ik nooit zijn voor een datamodel dat naar believen uit te breiden is. Daarmee heb ik al veel teveel mis zien gaan.

[JKVA]

Ze moeten dus zelf bij wijze van spreken extra attributen kunnen toekennen aan een entiteit?

Dan zou ik voor zoiets gaan:

code:

table crm_attribute
--------------
id
titel varchar
type id naar view ofzo // om het type te bepalen (email, sofi) die view bevat ook nog een kolom met het soort veld (varchar, numeric) zodat gekozen kan worden welke attribute_value kolom gepakt moet worden
required boolean
representation id naar view ofzo // om de weergave te bepalen

code:

table crm_attribute_value
--------------
id
fk_crm_attribute_id
value_varchar varchar // voor attributen met type varchar
value_numeric numeric // voor attributen met type numeric

code:

table crm_attribute_entity
--------------
id
fk_crmattribute_id
fk_entity1_id // join met medewerker
fk_entity2_id // join met werkgever
fk_entity3_id // join met nog iets anders

Ik heb ooit zoiets gemaakt, maar heb de sql niet meer. Er kunnen dus wat slordigheidjes in staan, maar het idee werkt op zich wel. Ook qua performance.

[reddog33hummer]

Anoniem: 130503 schreef op dinsdag 04 april 2006 @ 16:31:
Ik breek al een tijdje mijn hoofd over het opslaan van CRM (Customer Relationship Management) gegevens op een generieke manier. Met een systeem moeten verschillende partijen hun eigen CRM velden kunnen aanmaken, bewerken, verwijderen.

De vraag is; hoe sla je dit soort gegevens efficient op, zonder consessies te doen aan performance.

Expressievermogen en prestatie gaan hand in hand.
Des te meer expressievermogen je hebt (generieker) des te langzamer het wordt.
Dus het hangt af waar je de lijn trekt.

Welke taal gebruikt wordt voor de implementatie maakt me op dit moment niet zoveel uit, en ook de DBMS is niet zo van belang. Ik ben meer geinteresseerd in de concepten.

Das op zich het idee achter een dbms. Je hebt een generieke referentie waar jij je gegevens in kan uitdrukken. Je wil dus dynamisch de structuur van je informatie gaan veranderen (uitbreiden).

Er zijn verschillende mogelijkheden die ik overwogen heb;

1.) fysieke tabel bijhouden per gebruiker, waarin ieder CRM veld een attribuut is van de tabel. Dit zorgt voor snelle performance, maar qua onderhoud lijkt het me niet echt verstandig; wat zijn de consequenties voor het verwijderen van kolommen, of het toevoegen; hoe snel gaat dat?

Je zecht dat dit veel preformance oplevert. Ik denk het niet omdat je daarna de queries moet gaan doen op basis van complexe combinaties. Deze vaak gebruikte queries worden dus traag.

2.) Opslaan van velden en die koppelen aan instanties van velden die bij een enkele CRM kaart (gegevens van een persoon met daarin de attributen die aangemaakt zijn.) horen;

code:

table attribute
---------------------
pk_attribute_id
at_name

table crmcard
---------------------
pk_crmcard_id
... some general metadata about the card

table crmcard_data
---------------------
fk_attribute_id
fk_crmcard_id
da_value

Dit heeft echter een nadeel; elk CRM veld wordt opgeslagen onder eenzelfde type, terwijl er in de praktijk verschillende types zijn; leeftijd moet altijd een getal zijn, een regelige invoer ga je niet in een longtext veld gooien, een prijs is een float, etc.

Ik vraag me af of mensen hier ideeen hebben hoe je CRM gegevens op een generieke manier op kan slaan. Wat discussie met betrekking tot dit onderwerp is misschien interessant, dus schiet mij maar lek.

Optie 3.
In de DBMS moet de structuur aangemaakt worden en kan meestal ook aangepast worden.
Maak daar gebruik van. Dan ben je veel sneller omdat dan de gebruikelijke beredenatievermogens (en snelheid) blijven..

[The Eagle]

Tsja, ik zou je op zich wel een praktijkvoorbeeldje willen geven - maar dan maak ik proprietary sources publiek en dat mag geloof ik weer net niet
Ik werk zelf iig met PeopleSoft (ERP-pakket) en als ik zie hoe het daar gaatn, dan hebben we aparte tablespaces voor de systeemtabellen. Ook een veld wordt apart in een record gestopt, inclusief alle bijbehorende properties. Kost je even wat programmeerwerk, maar dan heb je ook wat
bij installatie worden gewoon scripts gedraaid die alle basistabellen aanmaken en van daaruit de rest installeren. Als je zo'n install doet, staat een Sun fire bak best wel even anderhalve dag te stampen

[Anoniem: 130503]

Ik heb zo'n vermoeden dat The_Eagle heeft wat ik zoek. Even heel duidelijk; de klant moet zelf CRM velden kunnen toevoegen en verwijderen.

Zo kan bijvoorbeeld T-Mobile een veld type_abo hebben, en een Belastingdienst een veel bsn (burger service nummer). De velden die op een CRM kaart staan moeten dus flexibel zijn.

De vraag is dus hoe je dit opslaat. De opmerking die reddog33hummer plaatst is inderdaad terecht, flexibiliteit en performance gaan niet altijd samen. Er is een omgekeerd evenredig verband.

Queries gaan eenvoudig als je een 'echte' tabel in de database aanmaakt. Gewoon eenvoudige selects op een enkele tabel.

Je krijgt dan dus tabellen als;

crm_tmobile
--------------------------------------
naam
adres
postcode
abonnement
belminuten
contractversie

crm_bakker
--------------------------------------
naam
postcode
aantalbakmachines


Extra tabellen houden vervolgens per colomn bij hoe het type in het systeem gerepresenteerd moet worden met een aantal vaste types.

Ik vraag me alleen af hoe tijdrovend het is om aan een tabel die misschien al 250.000 records bevat een extra colomn toe te voegen of te verwijderen.