(php/mysql) alles een node? Of: hoe generiek tag-systeem?

[Rekcor]

Hoi!

Ik ben bezig met het ontwerpen van een erp-achtig systeem. In dit systeem zitten orders, orderregels, klanten etc. Nu vroeg ik af of het volgende handig is

Het plan is om alles in de database een node te laten zijn (net als bv in Drupal). Je krijgt dan in de database een node-tabel, met generieke informatie van de node. Iedere andere tabel heeft dan als primary key 'nid', die verwijst naar de node-tabel.

Het voordeel is dat je bijv gemakkelijk tags kunt koppelen aan nodes. Het nadeel is dat de node-tabel erg groot kan worden (> 2.000.000 rijen). Daarnaast moet je voor iedere insert/delete een extra query draaien om de node-tabel up to date te houden.

Als dit geen goed plan is, hoe kan ik dan een tag-systeem maken (zoals bijv in dit forum) voor een generieke db structuur met een willekeurig aantal tabellen. Een tag moet gehangen kunnen worden aan willekeurig welke rij in willekeurig welke tabel.

[JaQ]

Rekcor schreef op vrijdag 08 maart 2013 @ 18:04:
Nu vroeg ik af of het volgende handig is

Als je een relationele database wilt gebruiken is dit een erg onhandig idee. Relationele databases zijn hier niet voor geschikt. Performance is ronduit kak als je dit soort constructies introduceert, tevens vertrouwen relationele databases op constraint die informatie over de inhoud verschaft aan de query optimizer. Iets wat onmogelijk is met zo'n datamodel.

Het klinkt meer alsof je iets nosql-achtigs zoekt.

[winkbrace]

Ja, dit klinkt inderdaad als de definitie van een nosql database. (check MongoDB)

Overigens zou ik voor een erp systeem absoluut een relationele database kiezen. Met goede indexen kom je dan ook een heel end.
Als je aan elk record in elke tabel een tag wilt kunnen hangen, moet je haast wel een heleboel mapping-tables bouwen die bijv `orders` linken aan `tags`. Zo'n tabel heeft dan 2 kolommen met de primary keys van orders en tags.
Maar dat brengt ons bij de vraag waarom je aan elke tabel een tag wilt hangen. Ik kan geen enkele situatie bedenken dat dat nodig is.

[Rekcor]

Bedankt!

Een use case voor tags is het maken van to-do-lijstjes, bijv. medewerker X die wil kunnen opslaan dat hij klant X moet bellen, product Y moet nakijken in het magazijn, persoon Z moet bellen.

Een andere use case voor tags is het maken van overzichten, bijv. laat alle items zien die medewerker X de afgelopen tijd heeft toegevoegd aan het systeem.

Ik ga nu waarschijnlijk voor:

tabel 'tags_dbtables': (int) tableId, (varchar) tablename
tabel 'tags': (int) tagId, (varchar) name
tabel 'tags_dbtablerows': (int) tagId, (int) tableId, (int) table_pk_value

Laatste tabel koppelt rijen in databasetabellen aan tags.

[TheNephilim]

Tags moet koppelen aan entiteiten, niet aan tabellen in je database. Een klant is een entiteit, een product ook.

[RobIII]

Rekcor schreef op maandag 11 maart 2013 @ 16:33:
Ik ga nu waarschijnlijk voor:

tabel 'tags_dbtables': (int) tableId, (varchar) tablename
tabel 'tags': (int) tagId, (varchar) name
tabel 'tags_dbtablerows': (int) tagId, (int) tableId, (int) table_pk_value

Ofwel je gaat voor de database-in-een-database. Is pas een stuk of 1000 keer besproken hier en telkenmale een slecht idee gebleken (afaik is dit de meest recente, maar er zijn zo nog -tig topics). Zo ook deze keer. Mark my/our words: je komt van een koude kermis thuis.

[ Voor 11% gewijzigd door RobIII op 11-03-2013 18:22 ]

[Rekcor]

RobIII schreef op maandag 11 maart 2013 @ 18:19:
[...]

Ofwel je gaat voor de database-in-een-database. Is pas een stuk of 1000 keer besproken hier en telkenmale een slecht idee gebleken (afaik is dit de meest recente, maar er zijn zo nog -tig topics). Zo ook deze keer. Mark my/our words: je komt van een koude kermis thuis.

Ik begrijp de (wat zuur overkomende) toon niet echt. Als ik de term 'database in een database' had gekend en/of herkend, had ik daar zeker eerst op gegoogled. Desondanks bedankt voor je reactie.

Aangezien ik aan SQL vastzit, is een nosql-oplossing een onbetreedbare weg.

Een andere oplossing zou kunnen zijn (variant op 'Drupal'-oplossing in TS) om alle entiteiten in het systeem een unieke id te geven. Je krijgt dan een hele simpele 'tabel':

'node_counter', met als enige veld (bigint) 'count'.

Iedere insert is dan:

SQL:

INSERT INTO <tablename>(primaryKeyColumn, ...) VALUES (SELECT count FROM node_counter, ...);

en dan

SQL:

UPDATE node_counter SET count=count+1;

Nadeel is dat je node_counter moet locken om te voorkomen dat je doublures krijgt....

Hoewel ik geen nadelen kan bedenken, komt de node_counter-tabel een beetje... vreemd over. Eigenlijk komt de hele opzet me een beetje vreemd over . Maar ik weet ook geen betere. Moet ik dan echt voor iedere entiteit een aparte 'koppelings-tabel' maken om de tags op te slaan?

[Janoz]

Je weet vooraf toch al je entiteiten? Waarom zou je aan je todo item niet gewoon optionele 3 FK's hangen. Naar klant, naar persoon en naar product? En mocht je aan een todo item meerdere items wilt kunnen hangen kun je er altijd nog een N:M relatie van maken.

Ik zie niet in waarom je voor deze redelijk beperkte functionaliteit (er zijn blijkbaar maar een paar usecases die dit vereisen en met een beetje aannames van mijn kant heb ik het idee dat het hierbij niet om de hoofd usecases gaat) het complete relationele deel van je database overhoop gooit.