Ga naar inhoud
Sidebar tonen Sidebar tonen
Geplaatst:

Ronald Kleverlaan

In relatie met mijn vorige posting:

 

In plaats van gebruik te maken van de MsSQL database werd me geadviseerd om over te stappen op de database Firebird. Heeft iemand hier ervaringen mee? Het schijnt ook op een Windows server te draaien (Kan niet overstappen naar Linux, heb helaas alle code draaien in ASP)?

 

Alvast bedankt,

 

Ronald

Passie voor ondernemerschap en crowdfunding en HL-er van het eerste uur.

Featured Replies

Geplaatst:

Rémy

Ik snap alleen niet waarom je van MSSQL afwil? Het is één van de beste database, dus waarom zou je willen overstappen als nu alles werkt.

 

Vanuitgaande dat je écht meer dan 100 tabbellen heb en veel queries (en sp's) hebt, dan zou een overstap handen vol met tijd en geld kosten, die volgens mij nooit terug te verdienen zijn. (Ben toch wel benieuwd waarom je zoveel tabbellen nodig hebt...)

 

En MySQL is geen serieuse vervanging kandidaat hiervoor. PostGrey misschien wel, maar dat werkt alleen op (l)unix.

 

-Rémy

Waar gewerkt word, worden fouten gemaakt.....

Ik ken mensen die nooit fouten maken....

Geplaatst:

Alef Arendsen

Remy, wat je zegt is helemaal waar, waarom overstappen als je een systeem hebt wat al werkt. Het kan natuurlijk zijn dat een goedkoper alternatief voor Kleverlaan aantrekkelijk is omdat hij z'n systemen/producten ineens op meerdere servers moet neerzetten wat meer licenties zou betekenen.

 

Wat betreft PostgreSQL (want dat bedoel je neem ik aan). Tegenwoordig draait dit wel op Windows, dus dat zou het probleem niet moeten zijn.

 

Over die 100 tabellen, tis zeker niet weinig, maar met een beetje systeem ben je er al snel (en dat heb ik het niet over een forum of een shop).

Geplaatst:

paulmatthijs

> En MySQL is geen serieuse vervanging kandidaat hiervoor.

 

geef daar dan eens wat redenen voor...

 

100 tabellen is zeker niet weinig, maar dingen als postnuke (cms geloof ik) gebruiken er ook al 100, dus dat zegt niet zoveel.

Geplaatst:

Gast Verwijderd account

  Op 13-7-2003 om 20:28, Rémy zei:
En MySQL is geen serieuse vervanging kandidaat hiervoor. PostGrey misschien wel, maar dat werkt alleen op (l)unix.

 

Voor deze uitspraak heb je blijkbaar een goede reden. Vertel meer! Ben namelijk benieuwd naar de motivatie.

 

Mijn motivaties om te kiezen voor OS zijn:

- Wellicht hebben ontwikkelaars als reden dat zij niet (meer) afhankelijk willen zijn van Microsoft en kiezen voor een OpenSource product.

- Als het nu wel werkt en de licentie kosten (zie onlangs!) worden gewijzigd kun je in de (financiele) problemen raken.

- Alle OS blijft ondersteund in de toekomst, wellicht in nieuwe versies of door jezelf omdat je de broncode kent.

 

* Uit de oude doos: Veel onder Clipper'87 ontwikkelde software werkte opeens niet meer onder Win 3.11, geen idee waarom. MS gaf geen ondersteuning voor oudere versies op dat moment. Gelukkig bleek een "Clipper-Crack" een oplossing te weten. Ook nu draait mijn oude Clipper'87 software nog steeds onder W9x.

Geplaatst:

Alef Arendsen

Hahaha, we blijven gaan met deze discussie... Blijft leuk om te zien hoe de meningen verschillen. Ook ik hou het gebruik van open source software zeker altijd in gedachte, maar heb wel m'n reserveringen...

 

  • Helaas worden oudere versie van open source software niet altijd ondersteund of bijgehouden. Daar zit je dan met je database die een bug heeft en niet meer gesupport wordt. Overgaan naar een nieuwere versie? Hmmm, soms geen optie omdat net die ene feature veranderd is...
  • Het blijft een afweging tussen wat je wil... Backup procedures in MySQL? Leuk, een bestandje kopieren, maar alle wijzigingen in tabel X sinds 12.05 uur vanmiddag ongedaan maken? Dat kan ik met Oracle in een handomdraai en met MySQL heb ik het nog nooit gezien. Het blijft een kwestie van eisen en wensen van de klant...
  • Dat je de broncode kent, wil nog niet zeggen dat je expert ben op het gebied van dat specifieke stuk open source. Problemen oplossen? Los jij voor mij dat ene probleem in die niet ondersteunde versie van MySQL met die blobs die niet gesaved worden als ze exact 2,8 megabyte zijn even op (ik noem maar een ridicuul voorbeeld)?

 

Blijft een kwestie van afwegen!

 

gr.

 

Alef

 

Geplaatst:

Rémy

  Quote
Het kan natuurlijk zijn dat een goedkoper alternatief voor Kleverlaan aantrekkelijk is omdat hij z'n systemen/producten ineens op meerdere servers moet neerzetten wat meer licenties zou betekenen.

Begrijp ik, maar óók al zou hij stukken goedkoper uit zijn qua licenties, met een andere RDBMS , dan denk ik dat de omzetting teveel geld zou kosten.

 

Waarom?

- Onderzoek:

Je dient eerst alle mogelijkheden te onderzoeken (steek je nu al tijd in). Vervolgens dien je je gemaakte keuze verder te onderzoeken op obstakels bij de omzetting (denk o.a. aan drivers, datatypes met andere kenmerken, etc.);

- Herschrijven:

Aangezien je al je stored procedures, triggers, DTS's, etc. in T-SQL zijn geschreven, die je allemaal dient te gaan vertalen in een ander SQLdialect. Óók dien je alle applicaties die deze RDBMS gebruiken te controleren en delen te herschrijven\veranderen.

- Nieuwe beperkingen:

Elke RDBMS heeft zwakheden die in acht genomen dienen te worden.

- Installatie en setupkosten

 

Als ik dan kijk naar 100 tabbelen met waarschijnlijk veel data, veel Stored Procedures en de applicatie(s) die deze data gebruikt, dan denk ik dit zoiets toch wel een jaartje gaat duren voordat goed en correct is omgezet en getest is. En dit kost dus veel geld. Ik kan dit natuurlijk niet in deze situatie beoordelen, maar zo'n overstap doe je niet even snel tussendoor.

 

  Quote
Tegenwoordig draait dit wel op Windows, dus dat zou het probleem niet moeten zijn.

Bedoelde inderdaad PostgreSQL ;D. Bij mij weten draait PostgreSQL nog niet native op Windows. Hiervoor is een extra layer nodig die unix emuleert: CygWin. En dit betekend performance-verlies en is daarom in mij ogen voor een productieomgeving nog niet geschikt. In versie 7.4 komt hopelijk wel native windowsondersteuning. Zie ook http://techdocs.postgresql.org/guides/Windows

 

  Quote
Over die 100 tabellen, tis zeker niet weinig, maar met een beetje systeem ben je er al snel (en dat heb ik het niet over een forum of een shop).
Ben ik met je eens, maar de reden dat ik het vroeg is om een inschatting te krijgen waarvoor de data gebruikt wordt (want als enkel voor een forum is, dan is de RDBMS niet goed opgebouwd) en dan kan ik ook een betere inschatting maken of overstappen laang gaat duren en veel geld gaat kosten.

 

Waarom is MySQL geen serieuse vervanging voor SQLserver? Elke professionele DBA zou je uitlachen als je zou voorstellen om SQLserver\Oracle te vervangen door MySQL. Waarom? Omdat het twee verschillende producten zijn: MySQL is een database, SQLserver een RDBMS!

 

Een RDBMS is je businesslogic. Dit kan alleen werken als deze basisdingen zoals foreign key's, views, stored procedures, triggers ondersteunt. MySQL ondersteund dit niet! Het zijn gewoon een paar losse tabellen zonder enige relatie tussen elkaar (zelfs MS Access doet dit beter)! Mocht het verschil tussen een database en een RDBMS nog niet duidelijk zijn, dan hoor ik het wel, want dan leg ik het wat uitvoeriger uit.

 

-Rémy

Waar gewerkt word, worden fouten gemaakt.....

Ik ken mensen die nooit fouten maken....

Geplaatst:

Alef Arendsen

Rémy (et al), ik kom hier nog op terug, heb er namelijk (uiteraard) wel wat over te zeggen. Ben alleen een beetje erg druk op het moment... Even geduld...

  • 2 weeks later...
Geplaatst:

Alef Arendsen

De manier waarop er geredeneerd wordt ben ik het helemaal mee eens. Zolang er maar niet vanuit een of ander fanatische pro- of anti-Microsoft filosofie gedacht wordt :)

 

Een aantal opmerkingen die een en ander misschien toch nog in perspectief zetten:

 

  Quote
Aangezien je al je stored procedures, triggers, DTS's, etc. in T-SQL zijn geschreven

Stored procedures, triggers, DTS's, T-SQL? Ik zal niet zeggen dat dit onbekende begrippen zijn voor mij, maar ik gebruik ze letterlijk nooit. Waarom niet? Omdat ik dit soort dingen niet door de database wil laten afhandelen.

 

  Quote
Een RDBMS is je businesslogic

Hier ben ik het volstrekt me oneens (waarschijnlijk voelde je hem al aankomen bij het vorige stukje). Een RDMS is wat mij betreft een systeem om data in op te slaan en data uit te halen, meer niet. Daarnaast moet het RDMS ervoor zorgen dat er van deze data afdoende backups gemaakt worden en dat ik eventueel terug kan naar eerdere versies van bepaalde data, etcetera. Business logic zit bij mij in de applicatieserver en niet in de database. Vandaar geen stored procedures, geen triggers, etcetera.

 

Zodra je het met bovenstaande in gedachte nog een keer benaderd, kun je tot de conclusie komen dat een database helemaal niet belangrijk is, zolang je maar gebruik maakt van standaard SQL (al dan niet gebruikmakende van een of ander abstractielaagje hiervoor). Dit betekent (voor ons tenminste) dat wij de database zonder al te veel werk kunnen vervangen door een andere (en ja, dit hebben we meerdere malen gedaan voor een datamodel van 100 tabellen, mede omdat er geen enkele stored procedure of trigger inzat).

 

 

Geplaatst:

Rémy

  Quote
Een RDMS is wat mij betreft een systeem om data in op te slaan en data uit te halen, meer niet.
Het feit dat jij een RDBMS alleen daarvoor gebruikt, betekend dat jij aan een database, zoals MySQL genoeg hebt. (En volgens mij zie je nog niet in wat stored procedures/triggers/views voor je kunnen betekenen. Als je er eenmaal mee werkt wil je niet meer terug ;))

  Quote
Zodra je het met bovenstaande in gedachte nog een keer benaderd, kun je tot de conclusie komen dat een database helemaal niet belangrijk is...
De gegevens(data) van een bedrijf is het meest belangrijkste wat er is, niet de applicaties, die kunnen opnieuw gebouwd worden. Deze gegevens dienen door een goede RDBMS beheert te worden, zodat kans op vervuiling of verlies van gegevens zo klein mogelijk wordt. Een RDBMS is een 'applicatie' die je data beheert, in de ruimste zin van het woord.
  Quote
...zolang je maar gebruik maakt van standaard SQL (al dan niet gebruikmakende van een of ander abstractielaagje hiervoor).
Standaard SQl? Elke database heeft een eigen SQL-dialect (heet T-SQL bij SQLserver) en óók al probeer je zo standaard mogelijk te werken het blijft een utopie een SQL-commando te hebben die in alle databases hetzelfde is. Simpele SQL-commando's zou misschien nog lukken, maar zodra het iets ingewikkelder wordt dan houdt het al op. Een abstractielaag in je applicatie wordt dan nutteloos, want je dient je SQL te herschrijven.

 

Maar waarom zou je niet alle handige speciefieke functies van de betreffende database gebruiken? Het vergemakkelijkt je ontwikkeling en in de praktijk wordt er zelden van database verandert.

 

De kans is veel groter dat er van applicatie verandert wordt... of men wil de data op meerdere manieren benaderen (webpagina, webservice, etc.). Hoe los je dit op? Al je businesslogic zit in je applicatie, zoals je zelf al zegt....

  Quote
Omdat ik dit soort dingen niet door de database wil laten afhandelen.
Waarom niet? Wil je dan al je businesslogic in elke applicatie, die gebruikt maakt van je data, implementeren....

 

Waarom niet de RDBMS een gedeelte van je businesslogic laten afhandelen en hier een abstractielaag in creëren, waardoor je applicatie hele simpele SQL-commando's naar de database kan sturen (zelfs zonder joins!)? Waarom zou je de applicatie de controle op de data uitvoeren, terwijl dit een taak is van de RDBMS. En hier zijn stored procedures, triggers en views uitermate belangrijk voor!

 

Laat ik het simpel uitleggen wat een goede RDBMS dient te doen:

1.Stel ik heb een 'flat database' en ik wil één kolom met unieke waarden hebben (bv. klantnr). Dan dien ik dit te controleren, door alle waardes te doorlopen. Dit zou ik in mijn applicatie moeten doen? Is het niet handiger om dit de RDBMS te laten doen? Natuurlijk! Daarom ondersteunen zelfs de simpelste databases dit.

 

2.Ik wil een uniek klantnr hebben dat oploopt. Moet ik alle klannr doorlopen en dan de hoogste klannr met 1 ophogen. Dit zou ik in mijn applicatie moeten doen? Is het niet handiger om dit de RDBMS te laten doen? Natuurlijk! Gelukkig ondersteunen ook veel databases dit.

 

3.Ik wil uit mijn klantentabel de straat\plaats verwijderen en deze in een postcode tabel zetten (normaliseren dus). In mijn klantentabel hoef ik dan alleen de postcode op te slaan. Maar deze postcode dient te bestaan in mijn postcode tabel (anders heb ik geen straat/plaats). Dus ik dien, voordat ik een postcode invoer in mijn klantentabel, te controleren of de postcode al bestaat in de postcodetabel. Dit zou ik in mijn applicatie moeten doen? Is het niet handiger om dit de RDBMS te laten doen? Natuurlijk! Alleen RDBMS ondersteunen dit... MySQL niet....

 

4.Ik wil dat als er een nieuwe postcode wordt ingevoerd in de klantentabel, er gecontroleerd word of deze voldoet (9999 AA-formaat) en automatische toegevoegd wordt aan de postcode tabel.Dit zou ik in mijn applicatie moeten doen? Is het niet handiger om dit de RDBMS te laten doen? Natuurlijk!

 

en wat ingewikkeldere mogelijkheden...

5.Ik wil dat elke nieuw ingevoerde postcode automatische gecontroleerd wordt met het postcode boek van TPG-POST bv. via internet.Dit zou ik in mijn applicatie moeten doen? Is het niet handiger om dit de RDBMS te laten doen? Natuurlijk!

 

6.Ik wil dat elke 5 minuten van mijn database een backup wordt gemaakt en ik een waarschuwing per e-mail, sms krijg als dit mislukt.Dit zou ik in mijn applicatie moeten doen? Is het niet handiger om dit de RDBMS te laten doen? Natuurlijk!

 

7.Ik wil één bepaalde actie op de database terugdraaien, maar alle acties daarna zijn wel correct en dienen gewoon uitgevoerd te worden.Is het niet handiger als een RDBMS dit kan? Natuurlijk!

 

8.Ik heb meerdere applicaties die een klant kunnen toevoegen. Ik wil de structuur van de klantentabel aanpassen, zonder elke applicatie aan te hoeven passen.Is het niet handiger als een RDBMS dit kan? Natuurlijk!

 

9.Ik wil alle werknemers inzage geven in de details van andere werknemers, behalve het prive-adres en het salaris, ook al zou je de applicatie hacken (of zelf bouwen\programmeren) dan nog kun je niet het prive-adres of salaris van een andere werknemer opvragen.Is het niet handiger als een RDBMS dit kan? Natuurlijk!

 

10.etc, etc...

 

Dit zijn een aantal voorbeelden, maar de strekking zal wel duidelijk zijn: Je kunt dus heel veel laten doen door je RDBMS, zonder dat je dit in elke applicatie dient te programmeren. Je applicatie wordt hierdoor veel 'lichter' en sneller en je kan makkelijker de database op ander manieren laten benaderen (bv. via internet) zonder bang te zijn dat je gegevens niet kloppen, immers je controles vinden plaats in de RDBMS, niet in de desbetreffende applicatie. Je hebt hiervoor een professionele DBA'er nodig om dit realiseren, bij voorkeur gespecialiseerd in de desbetreffende RDBMS (ben trouwens nog op zoek naar een nieuwe baan ;)).

 

Als je een RDBMS volledig gebruikt (dus niet alleen voor het opslaan\ophalen van data), dan is het onmogelijk om deze te laten vervangen door MySQL, die geeneens relaties tussen tabbelen onderling ondersteunt. En als ik lees dat de topic-starter stored procedures gebruikt, dan is MySQL geen optie voor vervanging.

 

Ben ook blij dat PHP MySQL niet meer standaard ondersteund (wat gezorgd heeft voor de bekendheid van MySQL), zodat PostgreySQL een kans krijgt en mensen realiseren wat een gemak een échte RDBMS je kan geven en het hopelijk meer keuze hebt bij hosting voor MySQL of PostgreSQL.

 

-Rémy

Waar gewerkt word, worden fouten gemaakt.....

Ik ken mensen die nooit fouten maken....

Geplaatst:

R.I.P. - Benm

Remy,

 

Het is grappig om te zien hoe jij bepaalde zaken vanaf de database benaderd, terwijl veel anderen dat vanuit de applicatie zouden doen. Waarschijnlijk maakt dat het verschil tussen programmeurs en DBA's, gewoon een andere insteek.

 

Veel van de zaken die je noemt kunnen voor mijn gevoel net zo goed door de applicatie gedaan worden, maar dan moet de DBA wel de programmeurs vertrouwen ;)

 

Natuurlijk mist MySQL best een aantal dingen die andere databases wel ondersteunen, ik denk daarbij aan zaken als stored procs, views en transacties. Een groot voordeel is dat er veel kennis is, het is niet moeilijk iemand te vinden die verder kan met een php/mysql applicatie.... en er is goede online documentatie. Het belang van dat laatste wordt nog wel eens onderschat, maar volgens mij is dat 1 van de dingen die zowel php als mysql groot hebben gemaakt.

 

 

 

Geplaatst:

Alef Arendsen

Leuke discussie!!! Typisch voorbeeld van een database-georiënteerde (Rémy) bouwer versus een applicatieplatform (dit geval J2EE) georiënteerde bouwer.

 

  Quote
Als je er eenmaal mee werkt wil je niet meer terug

Toen ik het opschreef had ik al zoiets van: hier hoor ik wat op terug. Nog steeds (en ik heb zeker wel eens met stored procedures gewerkt) zeg ik: ik gebruik ze niet...

 

  Quote
Een abstractielaag in je applicatie wordt dan nutteloos, want je dient je SQL te herschrijven

Dit is (in ons geval) niet waar. Ten eerste wat betreft de dialects. Je hebt uiteraard gelijk dat elke database zijn eigen dialect heeft. Dat dit voor Microsoft T-SQL is wist ik overigens niet. Dat ik geen stored procs en triggers en dergelijke gebruik resulteert in de mogelijkheid om door verandering van letterliijk één configuratie eigenschap (zelfs op runtime te veranderen), van database te wisselen! Ik zeg simpelweg tegen mijn persistence-framework, gebruik Oracle8i-dialect, Microsoft-dialect, MySQL-dialect en hij is aangepast (uiteraard na aanpassing van een url waar de database staat en toevoegen van een driver, maar dat is dan ook alles). Het persistence-framework regelt de rest voor me en ik hoef letterlijk geen regel aan m'n applicatie te veranderen.

 

  Quote
Het vergemakkelijkt je ontwikkeling en in de praktijk wordt er zelden van database verandert

Omdat ik ontwikkel vanuit een object model en niet vanuit een datamodel, wil ik eigenlijk alleen met het object model van doen hebben. Een persistency framework dient ervoor te zorgen dat de object de database in gepersist worden. Ik zou hiervoor bijvoorbeeld ook een OO-database kunnen gebruiken, maar die vind ik nog niet stabiel, krachtig en groot genoeg...

 

  Quote
of men wil de data op meerdere manieren benaderen (webpagina, webservice, etc.)

Business logic is in mijn geval niet het zelfde als het ontsluiten van deze businesslogic. Of ik een webapplicatie heb, een webservice, een fat-client, whatever, laat het een spraakgestuurde telefoonapplicatie zijn, de businesslogic blijft het zelfde (er is toch geen verschil tussen het overmaken van geld via de telefoon of direct bij de bank, behalve de manier waarop ik duidelijk dat ik geld wil overmaken). Loskoppelen van zogenaamde view, controller en model (welbekende MVC-paradigma) geeft de mogelijkheid om dit te doen. Zelfde businesslogic, wat mij betreft 6 views...

 

Goed - na de voorbeelden even gelezen te hebben - kan ik zo ongeveer 7 van de 9 punten omdraaien zodat ze vanuit de andere hoek geredeneerd even plausibel zijn... Een paar voorbeelden:

 

2. Hier ben ik het gedeeltelijk met je eens, al moet ik zeggen dat ik een uniek klantnummer liever zelf genereer. Je bent vast bekend met de (onder DBA'ers ook wel gevoerde) discussie of een tabel uniek identificeerdbaar moet zijn door z'n primary key of door een extra uniek veld (als klantnummer inderdaad). Wij handhaven bedrijfsspecifieke nummer (klantnummers, factuurnummers) niet als primary keys. Primary keys laten we inderdaad verzorgen door de datatabase (en bestaan naast de unieke nummers zoals klantnummer). Ik wil bijvoorbeeld een factuurnummer door een extern systeem (een webservice van Exact?) laten genereren, omdat ik dat helemaal mijn verantwoordelijkheid niet vind (en eergelijkgezegd ook niet die van de database). Het opvragen van dit factuurnummer is bijvoorbeeld een samenloop van debiteur en datum, data die ik toch al heb op het moment dat ik de factuur toevoeg. De database wil ik niet belasten met het contacten van dat externe systeem... Dus nee, liever niet door de database...

 

3. Hier kan ik niet snel een uitleg voor geven, maar dit wordt geregeld door m'n persistency-framework en heeft hetzelfde gedrag als jij schetst...

 

4. Validatie, interessant. Ik wil helemaal de database niet hitten om te controleren of de data valide is. Stel je voor dat ik twee applicaties heb, een web-applicatie. Er zijn twee clients, eentje ondersteunt JavaScript, de ander niet. Het zou mooi zijn om de validatie van de postcode op de ene client dmv JavaScript te laten doen (niet eens een round-trip naar de server, das wel zo lekker) en op de ander op de server. Dit kan ik doen, omdat de validatie niet zozeer onderdeel is van m'n businesslogic maar van m'n validatie-framework. Maar het zit in ieder geval niet in m'n database, want JavaScript generatie laten doen door m'n database? Neeeeee.... ;-). Daarnaast, ingewikkelder validatie als het volgende: een gebruiker voert een datum in in een bepaald formaat (wat afhankelijk is de taal van de gebruiker, denk aan 06-24-2003 versus 24/06/2003). Die taal van de gebruiker ken ik niet in de database en dat wil ik misschien ook helemaal niet (staat keurig in een cookie op de client of whatever). Validatie van deze formaten moeten dus in de applicatie (of liever het applicatie-framework) gebeuren en niet in de database...

 

5. Ik kan weinig anders zeggen dan dat ik vind dat dit soort dinge juist vanuit de applicatie moeten gebeuren. Connecten met een extern ERP-systeem (zoals eerder in het voorbeeld met Exact), een salarisverwerkingsysteem, vind ik onderdeel van m'n applicatieframework, niet van de database. Een mogelijke reden: m'n database staat achter de firewall en niet in de DMZ en heeft dus GEEN connectie met de buitenwereld (toch een veelgebruikte practice zou ik zeggen). Applicatieserver staat daar vaak wel (in de DMZ) en die heeft dus WEL connectie met de buitenwereld. Deze kan keurig een webservice op het internet aanspreken... Database achter de firewall, NIEMAND kan erbij...

 

6. !!!Helemaal gelijk, dit zijn precies de dingen die ik verwacht van een RDBMS. Maar dit is dan ook geen businesslogic (heeft niks te maken met geld overmaken van bank 1 naar bank 2), het gaat in dit geval om de betrouwbaarheid en veiligheid van m'n data en niet om transacties of whatever...

 

7. !!!Nogmaals: helemaal gelijk dit zijn dingen die ik van een RDBMS verwacht...

 

8. Er bestaat niet alleen de mogelijkheid om twee applicaties van één database gebruik te laten maken, ook om gedeelten van applicatie her te gebruiken. Op Microsoft platformen doet men dit door gebruik van bijvoorbeeld DLLs. J2EE (Java) met behulp van jars, en ingewikkelder wars, ears, ejbs, etcetera.

 

9. Ik zie het voordeel van views zeker wel, dit is ook zeker een van de dingen die ik graag zou willen combineren op de een of andere manier... Op dit moment hebben we dit in het applicatie-framework opgelost, maar hier heb je een punt!

 

  Quote
Dit zijn een aantal voorbeelden, maar de strekking zal wel duidelijk zijn: Je kunt dus heel veel laten doen door je RDBMS, zonder dat je dit in elke applicatie dient te programmeren

Herbruikbaarheid bestaat niet alleen in RDBMS's... Als ik iets voor de ene applicatie ontwikkeld heb, kan ik het naadloos herbruiken in een andere applicatie (uieraard alleen als ik er goed over heb nagedacht). Overigens ga je mij niet vertellen dat jij ook lang bezig bent met het in elkaar programmeren van ingewikkelder functionaliteit, algoritmes, etctera...

 

  Quote
MySQL, die geeneens relaties tussen tabbelen onderling ondersteunt

Ho hoo hoooo. Eerst kijken voor je iets roept. Zoals al eerder opgemerkt, is MySQL niet meer het databaseJE met weinig functionaliteit dat alleen voor PHP te gebruiken is. Mysql ondersteunt wel degelijk BLOBs, CLOBs, en bijvorbeeld ook relaties naar andere tabellen: alter table EMPLOYEE add index (LOGIN_ID), add constraint FK75C8D6AEA73745D1 foreign key (LOGIN_ID) references LOGIN (ID) (dit is overigens zomaar een stukje code wat ik normaal nooit zie omdat ik dit grotendeels laat maken door m'n persistency-framework).

 

Overigens ondersteunt MySQL in de laatste versies wel degelijk partial backups, partial restores, etcetera en zijn er commerciële addons (niet al te duur zelfs) die nog veel meer kunnen. Ik wil niet MySQL pushen, maar wil het simpelweg ook niet meteen de deur uitgooien en ten tweede, niemand heeft gezegd dat opensource software gratis is (dus waarom niet kleine addons bijvoorbeeld kopen).

 

Ik ben benieuwd. Alef

 

p.s. klein puntje van kritiek, er zijn mensen met andere meningen, dus tien keer in je email stellen dat het zo natuurlijk is dat je bepaalde dingen door een database wil laten doen en niet door een applicatieserver is niet zo netjes (ik deel je mening namelijk niet overal en dan komt zo'n statement nogal aanvallen over)...

p.p.s. het persistency-framework wat we overigens gebruiken is een O/R-mapper en die heet Hibernate (voor meer info, zie http://hibernate.sourceforge.net), net zoiets als TopLink of Cocobase

p.p.p.s. Misschien weet je een leuke titel voor deze discussie, ik vind Firebird database niet zo pakkend en wilde de discussie eigenlijk even afsplitsen naar een apart draadje...

 

 

 

 

Geplaatst:

Alef Arendsen

  Op 31-7-2003 om 09:51, Benm zei:

Het is grappig om te zien hoe jij bepaalde zaken vanaf de database benaderd, terwijl veel anderen dat vanuit de applicatie zouden doen. Waarschijnlijk maakt dat het verschil tussen programmeurs en DBA's, gewoon een andere insteek.

Veel van de zaken die je noemt kunnen voor mijn gevoel net zo goed door de applicatie gedaan worden, maar dan moet de DBA wel de programmeurs vertrouwen ;)

Ha Ben, je was me voor ;)

 

  Quote
transacties

Wel dus!!! MySQL is sinds de MAX versie (die InnoDB gebruikte en waarvoor je moest betalen) en sinds versie 4 (gewoon gratis) volledig ACID (en dit moet de transactionelen onder ons toch wel wat zeggen). Ook distributed transactions, net zoals elke andere volwaardige database!

Geplaatst:

R.I.P. - Benm

Klopt inderdaad, transacties zijn mogelijk vanaf 4. Helaas duurt het nog even voor deze database standaard beschikbaar is op allerlei servers, maar dat zit er natuurlijk aan te komen.

 

Wel hoor ik nog dingen over kinderziektes in 4.. gelukkig heb ik niet direct transactions nodig op het moment.

Geplaatst:

Rémy

  Op 31-7-2003 om 10:15, Aleph zei:
Leuke discussie!!! Typisch voorbeeld van een database-georiënteerde (Rémy) bouwer versus een applicatieplatform (dit geval J2EE) georiënteerde bouwer.
Heb lange avonden moeten doorhalen, dus kon helaas niet eerder reageren, maar het is inderdaad een leuke discussie. Of ik een database-georiënteerde bouwer ben? Zou kunnen :)

 

  Op 31-7-2003 om 09:51, Benm zei:
Het is grappig om te zien hoe jij bepaalde zaken vanaf de database benaderd, terwijl veel anderen dat vanuit de applicatie zouden doen. Waarschijnlijk maakt dat het verschil tussen programmeurs en DBA's, gewoon een andere insteek.
Ik ben begonnen als programmeur (en doe dit nog steeds), maar mijn denken over applicaties is toch veranderd. De database is voor mij de basis van elke applicatie, de onderste laag van een n-tier framework, dus benader ik zaken vanuit de database. Mmmm...lijkt er wel op dat ik een database-georiënteerde bouwer ben ;)

 

  Op 31-7-2003 om 09:51, Benm zei:
Veel van de zaken die je noemt kunnen voor mijn gevoel net zo goed door de applicatie gedaan worden, maar dan moet de DBA wel de programmeurs vertrouwen :)
En dat is het hem nou juist. Een DBA'er mag niemand vertrouwen, dit is zijn werk ;). De DBA'er dient o.a. voor de integeriteit van de data te zorgen en dit kan\mag je niet in de handen van de programmeur leggen, ook al zit deze aan de andere kant van het buro en drinkt hij af en toe een biertje met hem :). En zelfs als de programmeur dezelfde persoon is als de DBA'er, dan dient hij dit strict te scheiden. Een fout in de applicatie, mag geen invloed hebben op de integeriteit van de data. Nu klink ik wel heel erg als een database-georiënteerde bouwer ;).

 

  Op 31-7-2003 om 10:15, Aleph zei:
Nog steeds (en ik heb zeker wel eens met stored procedures gewerkt) zeg ik: ik gebruik ze niet...
Ik begrijp nu waarom door je uitleg over je persistence-framework dat je gebruikt (bedankt voor de link) en dit is op zich een hele andere benadering. Zelf zou ik hier nooit voor kiezen. Ik vind dat de RDBMS voor de dataintegeriteit dient te zorgen, niet een laag er boven.

 

  Op 31-7-2003 om 10:15, Aleph zei:
Loskoppelen van zogenaamde view, controller en model (welbekende MVC-paradigma) geeft de mogelijkheid om dit te doen. Zelfde businesslogic, wat mij betreft 6 views..
Je hebt gelijk dat je in J2EE dingen kunt hergebruiken (je businesslogic) voor verschillende applicaties, webservices, etc. Echter je bent nu wel gebonden aan java en dat is een keuze die ik persoonlijk niet zou maken.

 

 

Als ik jouw reactie van punt 3,4 en 5 samenvat begrijp ik jouw insteek, maar dan geef je het applicatieplatform de verantwoordelijk over de data(-integeriteit) en gebruik je database meer als een opslagmedium om je data op te slaan. Hier kun je voor kiezen, maar zelf vind ik dat de verantwoordelijk van de data bij de database hoort te liggen. Als de applicatieplatform weggevalt en je zou de database op een andere manier (bv .NET of direct via SQL) benaderen dan zou de database, in jouw geval, de dataintegeriteit niet kunnen behouden, want die zit in je applicatieplatform.

 

En speciefiek punt 4: Ik geef je helemaal gelijk dat je de database niet wil hitten voor datavalidatie. Ik zou dit bij de hoogste layer van een n-tier platform willen checken om onnodig beslag op de servers te vermijden. Maar dat wil niet zeggen dat de onderliggende layers de invoer niet hoeft te controleren (stel dat de laag er boven niet goed geprogrammeerd is). Ik vind dat de RDBMS alsnog de taak heeft om de data te controleren die ingevoerd wordt, want hij mag niet blind er vanuit gaan dat dit altijd correct is.

 

  Op 31-7-2003 om 10:15, Aleph zei:
MySQL niet meer het databaseJE met weinig functionaliteit dat alleen voor PHP te gebruiken is
Heb je gelijk in: MySQL ontwikkeld zich de goede kant, maar dingen zoals foreign key's, sub-selects, etc. werken alleen nog met bv. de InnoDB-type of in 4.1 (die nog een alpha-status heeft). En bij gebruik van de InnoDB-type, valt het voordeel van MySQL weg: snelheid. Andere databases, zoals PostgreSQL, zijn dan sneller... En hosting met InnoDB zijn er niet zoveel van....

 

Ik hoop juist dat ze MySQL goed doorontwikkelen, maar op dit moment hebben ze nog een flinke weg te gaan. Lees wel dat ze proberen storedprocedures, triggers en views in versie 5 te krijgen, dus dat ziet er hoopvol uit, maar eerst noemde ze dit soort dingen onnodig en onzinnig.... Als vervanging voor Oracle of SQLserver (als je deze producten tenminste volledig gebruikt) is het gewoon nog geen optie.

 

  Op 31-7-2003 om 10:15, Aleph zei:
klein puntje van kritiek
Je hebt gelijk: het komt inderdaad een beetje aanvallend over terwijl dit helemaal niet mijn bedoeling is.

 

 

  Op 31-7-2003 om 10:15, Aleph zei:
Misschien weet je een leuke titel voor deze discussie
Tja, de topicstarter heeft niet meer van zich laten horen (ben toch nog benieuwd of hij gaat overstappen) en de discussie is inderdaad een andere kant opgegaan, maar om het een goeie titel te geven: Enerzijds gaat het over de 'enterprise-'databases vs. de kleinere databases en of deze elkaar kunnen vervangen, anderzijds over welke taken een database dient te verichten en welke taken de applicatie (wat op zich ook weer meespeelt bij de keuze voor een enterprise\kleine database).

 

Een goede titel is dan denk ik: "Welke andere database kan mijn huidige (enterprise-)database vervangen?" (Blijft dan toch bij de vraag van de topicstarter, maar maakt het wat algemener ;))

 

-Rémy

Waar gewerkt word, worden fouten gemaakt.....

Ik ken mensen die nooit fouten maken....

Geplaatst:

FosKE

Ik wilde, als MSSQL fan :D, nog eventjes een feitje van Rémy een klein steuntje in de rug geven:

 

  Quote

Dit zijn een aantal voorbeelden, maar de strekking zal wel duidelijk zijn: Je kunt dus heel veel laten doen door je RDBMS, zonder dat je dit in elke applicatie dient te programmeren

 

Herbruikbaarheid bestaat niet alleen in RDBMS's... Als ik iets voor de ene applicatie ontwikkeld heb, kan ik het naadloos herbruiken in een andere applicatie (uieraard alleen als ik er goed over heb nagedacht). Overigens ga je mij niet vertellen dat jij ook lang bezig bent met het in elkaar programmeren van ingewikkelder functionaliteit, algoritmes, etctera...

 

Je kan idd je code hergebruiken in een andere applicatie, maar wat als je erachter komt dat je een fout hebt gemaakt, of niet zo zeer een fout, maar de klant wil een verandering? dan ben je met een stored procedure dus na 1x klaar, en met de sql apart in meerdere applicaties, ben je dus langer bezig.

 

Ook nog een klein puntje: door sommige taken, die afhankelijk zijn van van externe 'webservices' (met de kans dat ze niet beschikbaar zijn) te plaatsen bij de db, haal je de kans weg dat er fouten of lange wachttijden komen bij de gebruiker. Want terwijl jij gegevens alweer terug stuurt naar de gebruiker, kan de db op zijn gemak eens kijken of de service werkend is. Je hoeft de gebruiker dus niet op een timeout van bv. 10seconden te laten wachten. (dit geld natuurlijk wel voor gegevens die dus niet direct nodig zijn, maar bijvoorbeeld later wel).

 

Bjorn

ICStats analyseert, interpreteert en rapporteert over het bezoekersgedrag op uw website (We zijn ONLINE!)http://www.icstats.nl/
Geplaatst:

R.I.P. - Benm

Re-usability van allerlei zaken is een utopie uit de Object-Oriented wereld (ok, nu schop ik mensen, sorry). Het probleem is in mijn ervaring dat het idee wel goed is, maar dat de uitwerking vrijwel altijd faalt.

 

Stel je hebt een bepaalde procedure (in taalkundige zin) ingebakken in je database, maar op een gegeven moment kom je in de applicatie op een punt dat dat net even anders moet (dan dat gebeurd vaak genoeg). Je kunt nu een paar dingen doen:

 

1 - de procedure op je db aanpassen zodat hij beide mogelijkheden ondersteund

 

2 - vanuit de applicatie de data zodanig tweaken dat het met de bestaande procedure werkt

 

3 - to hell with it, direct uit de applicatie in de database drukken/hakken, bypassen die procedure

 

De eerste optie is aardig als dit 1 of 2 keer gebeurd. Als het nogal vaak gebeurd, kom je met een loei van een procedure te zitten waarin tig regels en uitzonderingen verwerkt moeten worden. De tweede vereist een programmeur met goed inzicht in de procedure, maar is zelfs dan niet altijd uitvoerbaar. De 3e mogelijkheid werkt altijd, maar ondermijnt het idee van de herbruikbare procedure volledig.

 

Alle methodes hebben hun voor en tegen, maar ik neig zelf altijd naar 3... komt waarschijnlijk omdat ik meer programmeur dan DBA ben. Vooral met 1 heb ik problemen, omdat de procedure dan zodaning complex wordt dat een programmeur er weinig inzicht in kan krijgen, of daarvoor zoveel tijd nodig heeft dat 3 significant sneller is. Blijft 2 over: goed voor mensen die zowel programmeur als DBA zijn :)

Geplaatst:

Ronald Kleverlaan

  • Auteur

Wow, aardige discussie is hierbij losgebarsten.

 

Ik heb er uiteindelijk toch voor gekozen om niet iets te gaan doen met Firebird. Dit was trouwens slechts een van de mogelijke alternatieven, maar ik heb gekozen om op MSSQL te blijven draaien.

 

Wel ben ik aan het plannen om het systeem zo om te bouwen, zodat we eind november de opzet klaar hebben om (indien nodig) meerdere servers te gaan koppelen om de kracht van het totale systeem te vergroten. Eerste stap is alles naar een nieuwe, grotere server overplaatsen. Als iemand hier nog kennis van het/iets over wil zeggen dan hoor ik dat natuurlijk ook graag....:) Wat zijn globaal gezien de belangrijkste oplossingen om het systeem te optimaliseren/versnellen?

 

Ter info: De applicaties en de database zijn al fysiek gescheiden systemen, dus daar is geen winst meer mee te behalen. De SQL database staat al op een geoptimaliseerde database server. Denk niet dat ik snel meerdere servers hiervoor nodig heb, maar vooral veel geheugen om bewerkingen uit te laten voeren heb ik me laten vertellen en een slimme afhandeling van queries.

 

Groeten,

ROnald

Passie voor ondernemerschap en crowdfunding en HL-er van het eerste uur.

  • 2 weeks later...
Geplaatst:

Alef Arendsen

  Quote

Mmmm...lijkt er wel op dat ik een database-georiënteerde bouwer ben

Ach, database-georiënteerd of niet, ieder heeft zijn mening denk ik. Ikzelf denk dat ik met mijn approach onze klanten het beste kan bedienen, jij waarschijnlijk ook, en uiteindelijk gaat het daar toch om: tevreden klanten!

 

  Quote

Echter je bent nu wel gebonden aan java en dat is een keuze die ik persoonlijk niet zou maken

Hmmm, niet voor de volle 100% gebonden aan Java. Ik heb het nooit gedaan, maar het is mogelijk om op de businesslogic laag (geimplementeerd in Java) een ASP of PHP frontend (VIEW alleen dus) te plakken... Is meer een academische beproeving dan dat het echt handig of efficient zal zijn, maar goed... Daarnaast hebben we meerdere heterogene systemen draaien die koppelen met Exact, Exchange en andere legacy/informatie/whatever-systemen.

 

Of de keuze voor Java wel of niet goed is, das een waarde-oordeel en moeilijk uit te spreken denk ik. Uiteindelijk denk ik dat ik met Java sneller, makkelijker en betere oplossingen kan leveren dan jij, maar goed, dat zeg jij ook, en dat moet ook zo blijven! Waarom zouden er anders meerdere technologiën bestaan...

 

Laatste punt: ik ben gebonden aan Java, maar jij bent gebonden aan bijvoorbeeld MSSQL (met z'n dialects, stored procs, etcetera). De producten/systemen die we willen leveren hebben een dermate hoge graad van herbruikbaarheid dat we database-onafhankelijk willen zijn. Ingeval een andere klant hetzelfde wil, maar in een Oracle db ipv een MSSQL db, hoeft ik niks te veranderen... Ligt een beetje aan wat je precies doet of je dit nodig hebt, wij wel in ieder geval.

 

  Quote

Want terwijl jij gegevens alweer terug stuurt naar de gebruiker, kan de db op zijn gemak eens kijken of de service werkend is

Een database is niet de enige plek waar asynchrone processing kan, dit is ook mogelijk op de applicatie laag. Vergis je niet in de mogelijkheden van een applicatieserver als bijvoorbeeld WebLogic, JBoss of iAS.

 

  Quote

Re-usability van allerlei zaken is een utopie uit de Object-Oriented wereld (ok, nu schop ik mensen, sorry)

Nee, je geeft een klein tikje tegen het scheenbeen... Ik ben het gedeeltelijk met je eens. Reusability is niet altijd mogelijk/haalbaar/wenselijk. Het kost vaak teveel tijd om voldoende na te denken over hoe iets moet gaan werken om het reusable te houden. Op object-oriented niveau is de vraag reuse wenselijk is heel legitiem. Zodra je op component-niveau diezelfde vraag nog een keer stelt wordt het (vind ik) ineens een hele andere situatie en zou je wel op reuse moeten focussen in mijn opinie...

Gast
Dit topic is nu gesloten voor nieuwe reacties.

Maak een account aan of log in om te reageren

Je moet een lid zijn om een reactie te kunnen achterlaten

Account aanmaken

Registreer voor een nieuwe account in onze community. Het is erg gemakkelijk!

Registreer een nieuw account

Inloggen

Heb je reeds een account? Log hier in.

Nu inloggen

Cookies op HigherLevel.nl

We hebben cookies geplaatst op je toestel om deze website voor jou beter te kunnen maken. Je kunt de cookie instellingen aanpassen, anders gaan we er van uit dat het goed is om verder te gaan.