:strip_icc():strip_exif()/u/108855/grootbeertje.jpg?f=community)
Ziehier de volgende web applicatie context (asp.net):
Een cms die enkel dient om data in te voeren. (php, mysql)
Vervolgens datalayer, business layer en een frontend (webforms c#). Deze waaier van 3 is het nieuwe systeem, sinds een half jaar.
Er is ook een indexing tool (solr/lucene), die items uit de trage cms database indexeert. Concreet worden de meeste woorden van het item geïndexeerd, gekoppeld met hun id; dit om zoekopdrachten in de frontend razend snel te maken. Solr geeft een collectie van id's die beantwoorden aan de zoekopdracht. Momenteel worden de items dan nog uit het cms gehaald en via custom ORM (hibernate of entities zijn ongeschikt momenteel) belanden ze in onze businesslayer.
Zoals al impliciet gezegd, lijkt het cms (php) en de database (mysql) nergens op kwa architectuur, normalisatie, ... de database is om te huilen, de php scripts ook. Tot overmaat van ramp is de API erop gewoon slecht en traag. Toch stapt onze klant in kwestie liever niet af van dit product.
Er worden momenteel twee mogelijkheden in acht genomen om de nieuwe web applicaties (frontend) snel te houden:
- ofwel gebruiken we onze indexer - solr - als een soort datawarehouse
- ofwel optimaliseren we de data uit het cms systeem en zetten het dus netjes in een correct geconfigureerde SQL-server(-database). Dit brengt dus een herhalende taak met zich mee van de data uit de cms d.b. te halen en deze automatisch in het nieuwe systeem te gieten. Naast het feit dat het ontwikkelen van deze algoritmes tijd in beslag neemt, is het overpompen van data misschien niet echt een probleem: men moet nu immers ook de indexer laten draaien na ingave van nieuwe zaken in het cms.
Nota: Solr gaat er niet tussenuit, die blijven we gewoon gebruiken voor zoekopdrachten (keuze van de klant) (en is nota bene verbluffend snel)
Wat zijn de "best practices" in dit geval? Het gaat dus over werkwijze, valkuilen, data-redundantie, onderhoud, ... en gewoon wat we nu eigenlijk best zouden doen.
Een cms die enkel dient om data in te voeren. (php, mysql)
Vervolgens datalayer, business layer en een frontend (webforms c#). Deze waaier van 3 is het nieuwe systeem, sinds een half jaar.
Er is ook een indexing tool (solr/lucene), die items uit de trage cms database indexeert. Concreet worden de meeste woorden van het item geïndexeerd, gekoppeld met hun id; dit om zoekopdrachten in de frontend razend snel te maken. Solr geeft een collectie van id's die beantwoorden aan de zoekopdracht. Momenteel worden de items dan nog uit het cms gehaald en via custom ORM (hibernate of entities zijn ongeschikt momenteel) belanden ze in onze businesslayer.
Zoals al impliciet gezegd, lijkt het cms (php) en de database (mysql) nergens op kwa architectuur, normalisatie, ... de database is om te huilen, de php scripts ook. Tot overmaat van ramp is de API erop gewoon slecht en traag. Toch stapt onze klant in kwestie liever niet af van dit product.
Er worden momenteel twee mogelijkheden in acht genomen om de nieuwe web applicaties (frontend) snel te houden:
- ofwel gebruiken we onze indexer - solr - als een soort datawarehouse
- ofwel optimaliseren we de data uit het cms systeem en zetten het dus netjes in een correct geconfigureerde SQL-server(-database). Dit brengt dus een herhalende taak met zich mee van de data uit de cms d.b. te halen en deze automatisch in het nieuwe systeem te gieten. Naast het feit dat het ontwikkelen van deze algoritmes tijd in beslag neemt, is het overpompen van data misschien niet echt een probleem: men moet nu immers ook de indexer laten draaien na ingave van nieuwe zaken in het cms.
Nota: Solr gaat er niet tussenuit, die blijven we gewoon gebruiken voor zoekopdrachten (keuze van de klant) (en is nota bene verbluffend snel)
Wat zijn de "best practices" in dit geval? Het gaat dus over werkwijze, valkuilen, data-redundantie, onderhoud, ... en gewoon wat we nu eigenlijk best zouden doen.
/u/12668/hydra.png?f=community)
:strip_icc():strip_exif()/u/75091/cgl213_rage_face.jpg?f=community)