[MySQL] Records verwijderen en aanmaken, of hergebruiken?

[Verwijderd]

Ik had een discussie met een programmeur. Die vertelde me dat hij nooit records verwijdert, maar deze gewoon aanhoudt als de gebruiker op 'verwijderen' klikt. Hij verwijdert ze dus niet, maar zet alle waarden op NULL, behalve de auto-id de waarde van 1 foreign key veld op NULL. Als hij dan een nieuwe record aanmaakt, kijkt hij eerst of er nog zo'n lege record is die kan worden hergebruikt. De reden is dat de records bij verwijderen wel uit het overzicht van de database verdwijnen, maar qua geheugen er toch nog in blijven hangen, en dus van invloed zijn op de (bestands)grootte van de database. Is dit nog zo in MySQL?

Ik zou zelf zeggen gewoon alles echt verwijderen. En bij een 'Voeg toe' actie wordt er dan altijd weer echt een nieuwe record aangemaakt.

Het lijkt me dat indien er meer records worden weggegooid dan dat er worden aangemaakt, de database in het aantal MB's misschien wel hetzelfde blijft, maar zodra je weer meer nieuwe records erbij hebt aangemaakt, dat hij dan wel eerst de lege ruimte in de database zelf netjes benut voordat de database weer groter wordt qua bestandsgrootte. Klopt dat een beetje?

[ Voor 6% gewijzigd door Verwijderd op 21-07-2014 20:45 ]

[Cyphax]

Alles op NULL zetten lijkt me een bizarre keus. Ik zou liever een boolean-kolom toevoegen met "deleted" en die gewoon op true zetten als je deletes wil echt wil voorkomen (wat geen exotische usecase is).

Hoe duur een delete is hangt onder andere af van je tabellen. Als je er tig indices op hebt liggen en die moeten bijgewerkt worden, dan kan het een dure operatie worden. Zelfde met foreign keys. Je zou dan even moeten nagaan wat de impact is van een delete.

Ik zou proberen om te voorkomen dat je gaat denken in "one size fits all"-achtige oplossingen en als je dat liever wel wilt, dan uitwijken naar een framework of CMS die je zelf de database laat regelen.

[ Voor 24% gewijzigd door Cyphax op 21-07-2014 20:34 ]

[DukeBox]

Daarnaast hangt fragmentatie ook erg af van de gekozen column types. Hoe dan ook is het idd een bizarre keuze. Idd een bool toggelen van active/inactive klinkt veel logischer. Dan kan je altijd achteraf een cleanup proces draaien.

[Verwijderd]

O ja, dat is sowieso beter natuurlijk, zo'n ja/nee veld.

// Edit: Oeps, ik zie nu dat ik hem verkeerd begrepen had. Hij zette slechts 1 veld op NULL (een foreign key veld). Als dat dan geen waarde had hergebruikte hij het. Excuses, mijn fout. Dus dat komt dan op ongeveer hetzelfde neer als een boolean veld.

Aha okee. Maar toch... Blijft de database dan toch wat 'vervuild' na deleten (even afgezien van het feit hoe duur de delete is)? Op http://stackoverflow.com/...-deleted-rows-get-re-used lees ik dat het niet uitmaakt, echt deleten en opnieuw aanmaken of hergebruiken. Even los van de tijd van een delete-query gezien...

[ Voor 63% gewijzigd door Verwijderd op 21-07-2014 20:47 ]

[DukeBox]

Daar heb je gewoon standaard mysqlcheck voor om af en toe de slack space op te ruimen.
Nogmaals, zonder te weten welke type columns er gebruikt worden kan je er niets zinnigs over zeggen. Als je een row her-gebruikt en je werkt met varchars die dan groter zijn krijg je meerdere ge-defragmenteerde blocks voor één record.

[Cyphax]

Verwijderd schreef op maandag 21 juli 2014 @ 20:37:

Aha okee. Maar toch... Blijft de database dan toch wat 'vervuild' na deleten (even afgezien van het feit hoe duur de delete is)? Op http://stackoverflow.com/...-deleted-rows-get-re-used lees ik dat het niet uitmaakt, echt deleten en opnieuw aanmaken of hergebruiken. Even los van de tijd van een delete-query gezien...

Ik weet niet hoe het allemaal is geïmplementeerd in MySQL (ik weet iets meer van SQL Server) maar het blijft afhangen van je tabelstructuur. Ik ga er een beetje vanuit dat bijvoorbeeld de volgorde van opslag van rijen afhangt van je primary key. Als je er eentje toevoegt komt ie gewoon aan het eind erbij.
Maar uiteindelijk komt het in principe gewoon neer op het volgende: zo'n DBMS is er wel op gebouwd om daar geen problemen mee te hebben. Als een DBMS erg vervuild raakt door een delete, dan is het niet zo'n best DBMS zou ik zeggen. Zolang je het niet over een exotisch iets hebt zou ik me er geen zorgen om maken zolang je niet delete-acties extra duur maakt.

[Verwijderd]

Aha okee. Dank jullie voor de input DukeBox en Cyphax, daar kan ik wel wat mee. Goed om te weten allemaal.

[Kalentum]

Bij MySQL zit je met grote verschillen tussen de meest gebruikte storage engines: MyISAM en InnoDB. Wat die programmeur doet heeft sowieso geen zin bij InnoDB, want die maakt bij elke update (dus ook bij het op NULL zetten van bepaalde velden) een nieuwe rij aan. Dat is bij InnoDB nodig omdat er mogelijk nog een transactie is van een andere sessie die nog de oude rij nodig heeft. InnoDB gooit dus nooit iets weg: een update leidt altijd tot een nieuwe database rij en het diskgebruik neemt dus voor eeuwig en altijd toe.

MyISAM doet niet aan transacties en in dat geval kan een rij wel daadwerkelijk worden vervangen. Maar dan nog doet die programmeur wat MySQL ook doet, want MySQL markeert een rij gewoon als 'gewist'.

[Gomez12]

rutgerw schreef op maandag 21 juli 2014 @ 21:31:
InnoDB gooit dus nooit iets weg: een update leidt altijd tot een nieuwe database rij en het diskgebruik neemt dus voor eeuwig en altijd toe.

Onderbouwing aub?

Want standaard geeft hij idd niet direct de ruimte vrij en heeft hij wel een mechanisme voor transacties etc. Maar er zijn afaik ook gewoon vacuum functies die je expliciet kan aanroepen, maar innodb zelf doet afaik ook gewoon aan housekeeping.

Wat ik denk dat je bedoelt is dat de interne housekeeping geen gereserveerde ruimte teruggeeft op schijf (maar waarom zou je dit ook automatisch willen, daar heb je expliciete commando's voor) waardoor je als je een lege db hebt en je gooit er 1 gig aan data in, dan is je db on disk 1 gig. Delete je alles in de db dan is je db leeg, maar je db-file is nog steeds 1 gig. Gooi je er daarna weer 0,5 gig data in dan is je db 0,5 gig en je db-file is nog steeds 1 gig.

Maar zo werkt bijna ieder server-based dbms, het verkleinen van data-files is te kostbaar om mee te nemen met interne housekeeping regels

[P.O. Box]

ik vind het maar een rare methode om rijen te "hergebruiken"...
misschien dat je het performance-wise merkt bij miljoenen records, maar ook dat vraag ik me af...

verder kun je een veld varchar(255) maken, maar als de waarde maar een paar bytes is, zoals bijv. "appel", dan neemt dit op de harde schijf maar een paar bytes in beslag.... stel nu dat de "nieuwe" rij (die dus over de oude rij heengeplaatst wordt) het woordje "appeltaart" bevat... dan neemt dit veld bijna 2x zoveel bytes in beslag... op de harde schijf had hij echter maar plaatst voor "appel", dus "taart" komt ergens anders te staan.... en zo fragmenteert je database lekker over de harde schijf heen...
of denk ik nu verkeerd?

[leuk_he]

Dit soort optimalisaties moet je echt aan de database overlaten. Er zijn scenarios waar dit goed zou kunnen werken, echter, als je insert nu opeens bestaat uit zoek naar null, insert, en dan overwrite dan duren al je inserts opeens 2x zo lang.

Doet me denken aan iemand die eerst tabel A uitlas, daarna tabel B, deze door unix sort en daarna via een merge de files weer inlas..... omdat unix sort zo snel was. ....(het is ook goed mogelijk dat hij een database outer join niet snapte...)

Leg je indexen goed, maak je datamodel correct, en als je dan nog performance problmen heb , dan ga je pas optimaliseren. (Tenzij je uiteraard een big-data applicatie hebt, daar is performance wel al vroeg belangrijk)

[The Eagle]

Lees je even in over datafiles icm highwatermark. Hoe het bin MySQL exact zit weet ik niet, maar in principe schrijft een DBMS altijd weg aan het einde van de datafile, en meestal ook bij updates. Het exacte mechanisme zal per DBMS verschillen, maar neem van mij aan dat er in datafiles heel veel lucht zit.
En idd, housekeeping daarvan is relatief duur, tijdrovend en meestal ook redelijk kritisch irt dataverlies. Dat laatste ivm export, drop en import (snelste manier). En dat gebeurt dus zelden

Ik weet niet hoe oud die programmeur is, maar ik vermoed dat ie een jr of 15 geleden wel gelijk had gehad. Tegenwoordig echter volledig achterhaald.

[GlowMouse]

rutgerw schreef op maandag 21 juli 2014 @ 21:31:
Wat die programmeur doet heeft sowieso geen zin bij InnoDB, want die maakt bij elke update (dus ook bij het op NULL zetten van bepaalde velden) een nieuwe rij aan. Dat is bij InnoDB nodig omdat er mogelijk nog een transactie is van een andere sessie die nog de oude rij nodig heeft. InnoDB gooit dus nooit iets weg: een update leidt altijd tot een nieuwe database rij en het diskgebruik neemt dus voor eeuwig en altijd toe.

Dit is onzin. Er is een undo-log voor oudere sessies.

Of het zin heeft, hangt sterk af van de tabel. Ik ga even uit van InnoDB. Rijen in InnoDB zijn gesorteerd op Primary Key; en in groepjes van 16 kB opgeslagen in een page. Hier een paar overwegingen:
- Een veld NULL-able maken, kost een byte per rij; meer als er een index op zit omdat die index dan ook een byte per rij extra inneemt.
- Leeghalen / hervullen heeft geen zin als de data in de PK-rijen wijzigt; de data verdwijnt dan alsnog in een andere page. Hierdoor ontstaat lege ruimte in de oude page. Een langdurige operatie is nodig om lege ruimte in pages terug te claimen. In de nieuwe page wordt mogelijk de limiet van 16 kB overschreden, waardoor de page gesplit moet worden. Hierdoor krijg je lege ruimte.
- Heb je geen PK gedefinieerd, dan wordt alles opgeslagen in de volgorde van invoer. Verwijderen zorgt voor lege ruimte in een page die nooit meer zal worden opgevuld. Pas wanneer alle data uit een page is verwijderd, krijg je die 16 kB weer terug.
- Staat de nieuwe data fysiek op dezelfde plek (zelfde PK, of geen PK gedefinieerd), dan is het van belang of de nieuwe rij meer data bevat. Je kunt dan de page limit overschreiden, waardoor je een page split krijgt.
- In de worst case heb je met verwijderen of met gewijzigde PK-velden, 16 kB pages die elk maar voor een paar bytes zijn gevuld. Je database is dan makkelijk 15x groter dan nodig. Dit is slecht voor caching en leessnelheid van disk.
- In de worst case heb je met hergebruik, als er geen PK is gedefinieerd of PK-data niet wijzigt, elke page voor gemiddeld minimaal de helft gevuld; en nog beter als de grootte van elke rij constant is.

[Laurens-R]

als het toenemen van de datafile je grootste zorg is kan je ook altijd nog een job inregelen die je database shrinkt, re-indexed, etc gedurende service windows oid. In SQL Server is dit vrij eenvoudig te doen. Je database blijft straight forward en je applicatie logica beperkt zich tot wat het functioneel moet doen.

Ik krijg altijd een beetje jeuk als een applicatie zoiets als een maintenance rol op zich neemt. Het maakt het ook lastig te doorzien of iets nou geïmplementeerd word vanwege een functionele requirement of dat het een technische issue oplost.

Lekker over laten aan het DBMS en de maintenance tools die daarbij horen

[ Voor 37% gewijzigd door Laurens-R op 22-07-2014 12:01 ]

[MSalters]

Ik zou het van een andere kant willen bekijken: is je database zo groot dat dit een probleem wordt, dan is het sowieso tijd om naar iets serieuzers uit te kijken dan MySQL - Postgres, een betaalde SQL database of misschien zelfs een niet-SQL database. Maar voor het kleine tot middelgrote werk waar je MySQL inzet maakt het linksom of rechtsom toch niet uit.

[GlowMouse]

MSalters schreef op dinsdag 22 juli 2014 @ 12:26:
Ik zou het van een andere kant willen bekijken: is je database zo groot dat dit een probleem wordt, dan is het sowieso tijd om naar iets serieuzers uit te kijken dan MySQL - Postgres, een betaalde SQL database of misschien zelfs een niet-SQL database. Maar voor het kleine tot middelgrote werk waar je MySQL inzet maakt het linksom of rechtsom toch niet uit.

Misschien moet jij MySQL eens van een andere kant willen bekijken. Er is geen reden om MySQL niet serieus te noemen.

[pedorus]

(Sharded) MySQL runt ook de grootste databases ter wereld (oa Facebook, Twitter), dus is zeker ook geschikt voor groot werk.

GlowMouse schreef op dinsdag 22 juli 2014 @ 00:46:
- Heb je geen PK gedefinieerd, dan wordt alles opgeslagen in de volgorde van invoer. Verwijderen zorgt voor lege ruimte in een page die nooit meer zal worden opgevuld. Pas wanneer alle data uit een page is verwijderd, krijg je die 16 kB weer terug.

Er zijn andere clustered indexes mogelijk: http://dev.mysql.com/doc/...n/innodb-index-types.html

Verder is dit wel erg pessimistisch, er kunnen pages samengevoegd worden door de purge thread(s):

quote: https://blogs.oracle.com/.../mysql_5_6_multi_threaded

Another benefit of purging separately in the background is that expensive B+Tree block merge operations, if the removal of the record were to lead to underflow, can be done asynchronously by purge and not by user transactions.

Terug op de TS: In zijn algemeenheid is "zelf verwijderen" implementeren bijna altijd meer werk en werkt het slechte performance eerder in de hand.

[GlowMouse]

pedorus schreef op dinsdag 22 juli 2014 @ 14:26:

[...]

Je hebt gelijk, zodra een page voor minder dan de helft (BTR_CUR_PAGE_COMPRESS_LIMIT) is gevuld, wordt geprobeerd of een merge mogelijk is met een neighbor.

[Gomez12]

GlowMouse schreef op dinsdag 22 juli 2014 @ 14:24:
[...]

Misschien moet jij MySQL eens van een andere kant willen bekijken. Er is geen reden om MySQL niet serieus te noemen.

Vergeet niet dat met MySQL de standaard download van de site (of de standaard package van de package manager) bedoeld wordt over het algemeen.
Ik heb over het algemeen meer zoiets van : Van MySQL wel iets serieus te maken, maar dat vereist wel allerhande aanpassingen / extra dingen etc.
En dat is allemaal niet erg als het je core is, maar is het niet je core dan kan het heel erg fout gaan met een default install.

pedorus schreef op dinsdag 22 juli 2014 @ 14:26:
(Sharded) MySQL runt ook de grootste databases ter wereld (oa Facebook, Twitter), dus is zeker ook geschikt voor groot werk.

Wat runt het dan exact? Want Twitter (en voor een heel groot gedeelte ook Facebook) heeft amper Relationele databases. Waar denk je dat de hele hoos aan NoSQL databases vandaan is gekomen?

Dat het een intern systeempje draait bij FB / Twitter is leuk, maar zegt weinig over de daadwerkelijke mogelijkheden.

[GlowMouse]

Gomez12 schreef op dinsdag 22 juli 2014 @ 14:59:
[...]

Vergeet niet dat met MySQL de standaard download van de site (of de standaard package van de package manager) bedoeld wordt over het algemeen.
Ik heb over het algemeen meer zoiets van : Van MySQL wel iets serieus te maken, maar dat vereist wel allerhande aanpassingen / extra dingen etc.

Dat valt wel mee. Veel features waarvoor je vroeger MySQL forks als Percona DB Server en MariaDB nodig had, zitten tegenwoordig ook in de standaard MySQL.

Wat runt het dan exact? Want Twitter (en voor een heel groot gedeelte ook Facebook) heeft amper Relationele databases. Waar denk je dat de hele hoos aan NoSQL databases vandaan is gekomen?

Dat het een intern systeempje draait bij FB / Twitter is leuk, maar zegt weinig over de daadwerkelijke mogelijkheden.

Hier een interview: http://www.mysqlperforman...h-5-facebook-mysql-gurus/
MySQL wordt oa. gebruikt voor de timeline: http://mashable.com/2011/12/15/facebook-timeline-mysql/

[Russel88]

Een database is gemaakt om data te updaten, inserten en op te halen.
Als je allerlei trucs verzint zoals je collega om je db sneller te laten werken dan overschat hij zichzelf. Ik kan wel begrijpen dat je records niet weg wilt gooien. Maar dat doe je niet vanwege performance, maar vanwege historie oid.
Vroegah hielden wij DeletedDate en DeletedBy bij. Niet vanwege de performance, maar omdat wij regelmatig telefoontjes kregen dat ze iets per ongeluks weg hadden gegooid. Nou ja, vaak begonnen ze dat data "opeens" verdwenen is. Dat klopt, dat heb je zelf verwijderd op <datum> knuppel. Velden leegmaken en factuurtje versturen.

[pedorus]

Gomez12 schreef op dinsdag 22 juli 2014 @ 14:59:
Wat runt het dan exact? Want Twitter (en voor een heel groot gedeelte ook Facebook) heeft amper Relationele databases. Waar denk je dat de hele hoos aan NoSQL databases vandaan is gekomen?

Dat het een intern systeempje draait bij FB / Twitter is leuk, maar zegt weinig over de daadwerkelijke mogelijkheden.

Mysql is dus de 'main' database van FB / Twitter, dus waar de timeline en tweets vandaan komen. Juist die NoSQL databases zijn voor andere zaken. Cassandra is bijvoorbeeld in gebruik bij Twitter (ex GNIP) als historische datastore met alle tweets, maar juist daarbij is het onduidelijk hoe dit geschaald kan worden als je bijvoorbeeld ook Weibo zou toevoegen of meer requests zou willen afhandelen. Cassandra is dacht ik niet meer in gebruik bij Facebook. Verder weet ik niet op welke NoSQL database je doelt. Iets als Mongo presteert bijvoorbeeld dramatisch als je over het werkgeheugen komt (of er zijn hidden settings die ik niet ken). Ik denk dat eigenlijk alleen HBase in de buurt komt van wat je bedoelt: http://www.theregister.co...7/facebook_messages_tech/ Maar goed er zal een reden zijn dat Twitter HBase alleen gebruikt als backup.

[Verwijderd]

Russel88 schreef op dinsdag 22 juli 2014 @ 15:38:
Een database is gemaakt om data te updaten, inserten en op te halen.
Als je allerlei trucs verzint zoals je collega om je db sneller te laten werken dan overschat hij zichzelf. Ik kan wel begrijpen dat je records niet weg wilt gooien. Maar dat doe je niet vanwege performance, maar vanwege historie oid.
Vroegah hielden wij DeletedDate en DeletedBy bij. Niet vanwege de performance, maar omdat wij regelmatig telefoontjes kregen dat ze iets per ongeluks weg hadden gegooid. Nou ja, vaak begonnen ze dat data "opeens" verdwenen is. Dat klopt, dat heb je zelf verwijderd op <datum> knuppel. Velden leegmaken en factuurtje versturen.

Mooi! Zoiets deed hij trouwens ook, en daar is 1 medewerker door ontslagen. Die was namelijk de hele dag met andere dingen bezig. Maar het systeem hield namelijk ook bij wanneer hij ingelogd en aan het werk was.

Over die grootte van een MySQL database: Als je nou bijvoorbeeld kijkt naar Exact Online, daar moeten duizenden klanten de boekingen van hun boekhouding in doen, zodat je waarschijnlijk totaal miljoenen of miljarden boekingen hebt van al die klanten. Zo te zien is het gemaakt met .NET (ik zie een inlogscherm op een .aspx pagina). Welke database daar gebruikt wordt weet ik niet. Maar gezien Twitter en Facebook MySQL gebruiken (wat ik in de comments hier lees), moet dat voor zoiets dan ook wel lukken? Of zal daar voor elke klant zijn eigen databaseje worden aangemaakt? Dit is zomaar een voorbeeld hoor, maar ik was benieuwd hierover, omdat we het over de (mogelijke) groottes van databases hadden.

[PsychoMantis_NL]

Wij doen op kantoor de boekhouding via exact online voor een stuk of 100 klanten en voor zover ik heb kunnen ontdekken draaien die niet per klant in een aparte database. Zou me ook een beetje dubbelop lijken aangezien er heel veel dingen in iedere administratie hetzelfde zijn, ondanks dat de grootboekrekeningen anders zijn.. Het blijft xxx voor xxx euro Aan xxx voor xxx euro

Lijkt me dat daar een ownerId oid achter hangt, vooral als je dat dus combineert met onze werkzaamheden als accountantskantoor. Ik heb 1 hoofdadministratie vanwaar ik administraties van klanten benader met dezelfde (mijn eigen) gegevens.

Edit: de klant kan, maar hoeft niet per se toegang te hebben tot die administratie, net zo als dat zij eigenaar kunnen, maar niet hoeven zijn van de betreffende administratie

[ Voor 12% gewijzigd door PsychoMantis_NL op 22-07-2014 21:01 ]

[pedorus]

Het lijkt me eigenlijk dat iets als Exact een database per administratie heeft (MS SQL server in het geval van Exact). Dit voorkomt dat er bij een foute query data bij de verkeerde klant terecht komt, en maakt het makkelijker om iets met een hele administratie te doen, zoals backup/restore en alle data verwijderen. Om de redenen die in dit topic staan kost dat anders opeens een stuk meer tijd en levert het fragmentatie op.

Daarnaast wil je ook niet te grote tabellen. Ik heb het met MS SQL nooit uitgeprobeerd, maar met MySQL is het vervelend als je een ongepartioneerde tabel met meer dan 10M rijen hebt, dan begint de performance te wensen over te laten. Replicatie in MySQL 5.6 werkt slechter als je maar 1 database hebt (dan single threaded). Dit zijn ook redenen dat het met een database per administratie gewoon veel schaalbaarder is. Aan de andere kant is er overigens ook een overhead per tabel, dus overmatig opsplitsen is ook mogelijk.

Toegang lijkt me los te staan van hoe je data opsplitst. Juist uitwisseling van administraties met accountants lijkt me ook een reden om aparte databases te hebben, die je makkelijker los kan kopiëren of apart toegang toe kan geven. Je hebt hooguit een centrale database nodig voor die toegang, maar zelfs dat is niet strikt noodzakelijk.

[RobIII]

Ik weet iig dat van "on premise" Exact versies bij accountantekantoren (iig bij de onze ) gewoon een crapload aan DB's in SQL Server hangt (althans; dat was tot voor kort zo, is wel weer éven geleden _{Ik moet nog ergens een screenshot hebben van een SQL server met 100+ databases (001, 002, 003 ...)}). En het zou me verbazen als dat bij Exact Online anders was; daar heb ik vandaag 3 .bak (MSSQL backup) bestanden naartoe gestuurd die ze "aan hun kant" zouden importeren (lees: restoren).

PsychoMantis_NL schreef op dinsdag 22 juli 2014 @ 20:59:
Lijkt me dat daar een ownerId oid achter hangt, vooral als je dat dus combineert met onze werkzaamheden als accountantskantoor. Ik heb 1 hoofdadministratie vanwaar ik administraties van klanten benader met dezelfde (mijn eigen) gegevens.

Je kunt in MSSQL (maar in veel andere RDBMS's ook) prima cross-DB queries draaien;

SQL:

select *
from db_A.dbo.sometable
inner join db_B.dbo.othertable on db_A.dbo.x = db_B.dbo.y
...

of...

SQL:

select *
from db_A.dbo.sometable
union all
select *
from db_B.dbo.sometable
...

...bijvoorbeeld.

Dus dat hoeft geen probleem te zijn

(Het kan zelfs cross-server als je server1.mydb.dbo.sometable gebruikt (en de server toevoegt met sp_addlinkedserver) waarbij die andere server zélfs een compleet ander RDBMS kan zijn als deze maar als OLE DB aan te spreken is; maar dat geeft uiteraard wel wat meer 'wrijving' ).

Ik zeg hiermee dus niet dat Exact Online meerdere DB's gebruikt, maar wél dat ik die kans behoorlijk hoog acht.

[ Voor 79% gewijzigd door RobIII op 22-07-2014 23:00 ]

[PsychoMantis_NL]

Nu ik e.e.a. nog eens doorlees lijkt me dat inderdaad een stukje praktischer als overal een ownerId achter plakken. I stand corrected

[alienfruit]

Licht er helemaal aan wat voor product of dienst het is. Ik werk aan veel projecten/diensten waar je niet eens de records echt mag verwijderen. Voornamelijk geforceerd door 'company policy', lol

[Verwijderd]

pedorus schreef op dinsdag 22 juli 2014 @ 22:27:
Het lijkt me eigenlijk dat iets als Exact een database per administratie heeft (MS SQL server in het geval van Exact).

...

Toegang lijkt me los te staan van hoe je data opsplitst. Juist uitwisseling van administraties met accountants lijkt me ook een reden om aparte databases te hebben, die je makkelijker los kan kopiëren of apart toegang toe kan geven. Je hebt hooguit een centrale database nodig voor die toegang, maar zelfs dat is niet strikt noodzakelijk.

Hmmm, even denken. Stel dat elke klant zijn eigen database heeft, hoe werkt dat dan met die toegang? Die is dus wel centraal geregeld, met alle users en wachtwoorden op 1 database? Hoe zie ik dat dan op een PHP-pagina? Bovenaan de PHP pagina checkt de sessie of een bepaalde user ingelogd mag zijn aan de hand van de centrale database en daarna/daarnaast wordt een connectie gemaakt met de eigen database van de klant om al zijn/haar dingen te beheren?

[The Eagle]

Ik mag hopen dat Exact voor iedere klant een aparte applicatieserverinstance neerzet die op zijn beurt connectie maakt met de DB en het juiste schema. En de gebruiker connect weer naar de juiste applicatieserver natuurlijk

[Creepy]

Voor elke klant een aparte applicatieserver? Lijkt me een beetje overkill eerlijk gezegd. Een database per klant kan je op meer manieren oplossen dan gelijk met een applicatieserver. Hier hebben we een class die per klant wordt geinstantieert die de connectionpool voor die klant heeft. Via die instantie krijgt de overige code een eventuele DB connectie uit de pool.

[Gomez12]

Verwijderd schreef op donderdag 24 juli 2014 @ 15:55:
[...]
Hmmm, even denken. Stel dat elke klant zijn eigen database heeft, hoe werkt dat dan met die toegang? Die is dus wel centraal geregeld

Even ongeacht hoe exact het ingeregeld heeft (zo moeilijk is dat namelijk niet).
Als jij er niet uitkomt is het ook gewoon een mogelijkheid om het helemaal niet centraal en onder het mom van klant-vriendelijkheid / klantherkenbaarheid het allemaal onder subdomeinen te gooien, dan heeft iedereen zijn eigen subfomein waardoor er een herkenbare url verschijnt (althans dat is het verkoop verhaal, in werkelijkheid is er dan gewoon niets centraals nodig)

Maar ik heb een beetje het idee dat je iets aan het bouwen / laten bouwen bent. Dat is natuurlijk leuk en mooi, maar praktisch gezien wil je dan eigenlijk niet kijken naar iets als exact online, want :
- Het heeft heel gevoelige info dus daar zijn andere eisen voor
- Het heeft een bepaalde achtergrond en daarom worden er bepaalde keuzes gemaakt, als jij die achtergrond niet hebt dan zou ik niet dezelfde keuzes maken als exact...

Voornamelijk het 2e is imho essentieel. Exact online is eigenlijk begonnen alszijnde een los draaiend pakket wat al bij x duizend klanten draaide op losse databases en dat moest even "online" gegooid worden zonder dat er 10 jaar aan verbouwd moest worden.
Oftewel het waren voor online 10.000 dbases, neem de beslissing om het in online ook op 10.000 dbases te draaien et voila, 99% van je backend is al klaar voor online door enkel een connectie-string aan te passen.

Het scheiden van klanten / dbases / data etc kan op vele manieren, maar als je nu programmatuur op de plank hebt liggen die werkt op manier x en waar al jaren tegenaan geprogrammeerd is, dan is er eigenlijk geen andere manier dan x meer.

[kwaakvaak_v2]

Creepy schreef op donderdag 24 juli 2014 @ 20:57:
Voor elke klant een aparte applicatieserver? Lijkt me een beetje overkill eerlijk gezegd. Een database per klant kan je op meer manieren oplossen dan gelijk met een applicatieserver. Hier hebben we een class die per klant wordt geinstantieert die de connectionpool voor die klant heeft. Via die instantie krijgt de overige code een eventuele DB connectie uit de pool.

Ik weet niet hoe Exact online het doet, maar Exact globe enterprise heeft voor iedere administratie een losse DB. Elke administratie heeft een nummer, en elk nummer is dus een losse DB in een SQLServer omgeving. In de applicatie ini file staat de connectie string naar die DB, zonder authenticatie want dat wordt op windows niveau al geregeld. Heb ooit een keer voor een redelijk grote toko met wat performance / scaling issues de verschillende administraties verdeeld over meerdere fysiek losse SQL servers.

Hmmm, even denken. Stel dat elke klant zijn eigen database heeft, hoe werkt dat dan met die toegang? Die is dus wel centraal geregeld

Jups.. bij Enterprise zit dat dus gewoon in de AD en hangt het aan je user account vast.

[ Voor 10% gewijzigd door kwaakvaak_v2 op 25-07-2014 09:26 ]

[Verwijderd]

Gomez12 schreef op donderdag 24 juli 2014 @ 23:27:
[...]

Even ongeacht hoe exact het ingeregeld heeft (zo moeilijk is dat namelijk niet).
Als jij er niet uitkomt is het ook gewoon een mogelijkheid om het helemaal niet centraal en onder het mom van klant-vriendelijkheid / klantherkenbaarheid het allemaal onder subdomeinen te gooien, dan heeft iedereen zijn eigen subfomein waardoor er een herkenbare url verschijnt (althans dat is het verkoop verhaal, in werkelijkheid is er dan gewoon niets centraals nodig)

Maar ik heb een beetje het idee dat je iets aan het bouwen / laten bouwen bent. Dat is natuurlijk leuk en mooi, maar praktisch gezien wil je dan eigenlijk niet kijken naar iets als exact online, want :
- Het heeft heel gevoelige info dus daar zijn andere eisen voor
- Het heeft een bepaalde achtergrond en daarom worden er bepaalde keuzes gemaakt, als jij die achtergrond niet hebt dan zou ik niet dezelfde keuzes maken als exact...

Voornamelijk het 2e is imho essentieel. Exact online is eigenlijk begonnen alszijnde een los draaiend pakket wat al bij x duizend klanten draaide op losse databases en dat moest even "online" gegooid worden zonder dat er 10 jaar aan verbouwd moest worden.
Oftewel het waren voor online 10.000 dbases, neem de beslissing om het in online ook op 10.000 dbases te draaien et voila, 99% van je backend is al klaar voor online door enkel een connectie-string aan te passen.

Het scheiden van klanten / dbases / data etc kan op vele manieren, maar als je nu programmatuur op de plank hebt liggen die werkt op manier x en waar al jaren tegenaan geprogrammeerd is, dan is er eigenlijk geen andere manier dan x meer.

Hehehe, dat is mooi gebracht ja.

Nee, we zijn niets aan het bouwen. Maar ik heb het wel met die programmeur (inderdaad is hij met eind in de 40 jaar al wat ouder, zoals iemand zich in deze draad al afvroeg) erover gehad over hoe de database (1 of meerdere) op te zetten bij bijvoorbeeld zoiets als Exact Online.

Het is meer een algemene vraag, wel of niet centraal? Het zal inderdaad met de gevoeligheid van de data te maken hebben. En of er data tussen de users moet kunnen worden uitgewisseld. Dus bij gevoelige data en als er niets hoeft worden uitgewisseld, zal het wellicht beter zijn om iedereen een eigen database te geven. Ook het feit dat de ene persoon er misschien maar 100 records in zet en een andere misschien wel een miljoen. Wellicht is er dan toch wat beter te scalen; persoon X misschien overhevelen naar een eigen DB server?

Als je het voorbeeld van Exact Online nog eens neemt, en dan niet kijkt naar de historie (met allemaal losse databases), maar als je zoiets from scratch zou moeten bouwen, dan zou je toch in hun geval kiezen voor allemaal losse db's? Gezien de gevoeligheid van de data, scalability en het feit dat iedere klant toch alleen zijn eigen data hoeft te zien (er hoeft niet uitgewisseld of vergeleken te worden tussen users). Of zijn er dan toch ook redenen om centraal te gaan?