Applicatie + website met zelfde databank

[Verwijderd]

Dag iedereen,

Ik heb momenteel een projectje waarmee ik facturen kan maken en de stock beheren. Ik zou hier graag een webshop aan koppelen, maar ik weet niet goed hoe ik dit het best doe.

Mijn project is geschreven in VB.NET en ik maak gebruik van een access database. Dynamische websites opzetten doe ik met behulp van PHP. Op school leerden we echter PHP te combineren met mySQL, wat ik ook een zeer goede keuze vind.

Conclusie:

• VB.NET kan werken met een mySQL databank, maar dit is iets moeilijker (geen default connectors in Visual Studio & de xsd-file kan ik niet meer gebruiken)
• PHP kan overweg met een access-database

Dus, wat moet ik doen? Ik zette al even enkele mogelijke oplossingen op een rijtje.

• Moet ik mijn access-databank vervangen door een mysql databank?
• Moet ik PHP gebruiken in combinatie met een access-databank?
• Moet ik mijn project herschrijven in een andere programmeertaal, zodat ik gemakkelijker kan werken met een mysql-databank?

Wat is de meest voor de hand liggende keuze? Mijn gebrek aan ervaring (ben een laatstejaarsstudent in het middelbaar) laat mij in de steek.

[Avalaxy]

Je kunt ook gewoon vanuit je applicatie connecten met je database via een webservice zoals SOAP. Kun je PHP gewoon de mysql handling laten regelen, en kun jij gemakkelijk die SOAP functies aanroepen.

[ Voor 3% gewijzigd door Avalaxy op 21-06-2010 19:04 ]

[fanne]

Beste,
ik denk dat het beste is om met een MySQL databank te werken. Dit houdt dus in dat je je databank gaat moeten omvormen naar een MySQL databank. MySQL heeft vele voordelen boven Access. Het is een echte server, is heel wat performanter, en zorgt ervoor dat je gegevens centraal staan (en op een andere locatie als het programma).

[fleppuhstein]

MySQL zelf onderhoud een groot aantal connectors, waaronder eentje voor .NET. Welke overgens prima werkt uit eigen ervaring. Wel een eigen manager wrapper om heen geschreven om slechts een enkele connectie te gebruiken.

Linkhttp://www.mysql.com/products/connector/

[ Voor 11% gewijzigd door fleppuhstein op 21-06-2010 23:33 . Reden: Link toegevoegd ]

[HuHu]

Komt het überhaupt op dezelfde server te draaien? Meestal draait een applicatie voor facturatie en voorraad intern binnen een bedrijf en een website draait op een externe webserver. Dan is het sowieso niet handig om dezelfde database server te gebruiken, dus dan ben je ook direct niet meer gebonden aan het gebruik van dezelfde database server software.

Je moet dan wel synchroniseren (wellicht eenzijdig).

[cariolive23]

Access is snel om te zetten naar SQL Server (Express versie is gratis), dat is een echte database en zeker een factor 100 beter en betrouwbaarder dan MySQL. SQL Server is ook eenvoudig via PHP te benaderen, geen enkel probleem, zie de PHP handleiding.

[HuHu]

Kun je die factor 100 uitleggen?

[cariolive23]

HuHu schreef op dinsdag 22 juni 2010 @ 09:30:
Kun je die factor 100 uitleggen?

Zie de handleiding van MySQL, staat precies in hoe je e.e.a. goed en/of fout kan configureren. Per query, per connectie, per database, per server, per engine kan het gedrag van queries totaal verschillen. Je weet dus nooit waar je aan toe bent, er is niet te garanderen dat je met dezelfde data altijd dezelfde resultaten krijgt met dezelfde query. En dat is gedrag wat je niet wilt hebben, zeker niet met iets wat een RDBMS moet voorstellen.

MySQL is trouwens één van de weinig databases met dit rare gedrag, zelfs Access heeft dit niet.

Mijn ervaring (7 jaar software testen) leert dat minstens 80% van de applicaties/scripts met MySQL-databases grove fouten in de SQL heeft zitten die met andere databases niet zouden voorkomen, die geven direct een foutmelding op foute constructies. Dit maakt MySQL dan ook een kostbare database, je bent meer tijd (en dus geld) kwijt met bouwen, testen en debuggen.

Hier een bekend lijstje met een aantal problemen (er zijn er nog veel meer), sommige zijn inmiddels verbeterd, hou dus de versienummers in de gaten.
http://www.yapf.net/index...n_van_MySQL_op_een_rijtje

[HuHu]

Ik zie eerlijk gezegd geen problemen als je gewoon de nieuwste versie neemt (MySQL 5.1) en eenvoudige dingen er mee doet. Dat je in veel applicaties fouten vind zegt misschien meer over de programmeurs van die applicaties dan de gebruikte database.

De voordelen van MySQL zijn dusdanig groot, zeker voor webapplicaties, dat je beter daar voor kunt kiezen.

[cariolive23]

HuHu schreef op dinsdag 22 juni 2010 @ 10:56:
Ik zie eerlijk gezegd geen problemen als je gewoon de nieuwste versie neemt (MySQL 5.1) en eenvoudige dingen er mee doet. Dat je in veel applicaties fouten vind zegt misschien meer over de programmeurs van die applicaties dan de gebruikte database.

Uiteraard zijn het fouten van de programmeurs, dat zijn ook maar mensen, die maken dus ook fouten. Het zou alleen veel tijd en geld schelen wanneer deze fouten direct aan het licht komen en niet pas nadat er uitgebreid is getest of zelfs in productie (je test tenslotte nooit 100% van je applicatie).

De voordelen van MySQL zijn dusdanig groot, zeker voor webapplicaties, dat je beter daar voor kunt kiezen.

Die is gek, MySQL is leuk als kladblok, als RDBMS is het totaal onbruikbaar omdat het gewoon niet betrouwbaar is. Zelfs backups zijn onbetrouwbaar, standaard wordt niet de complete database in de backup gezet maar slechts een deel. Een backup restoren in een versie die niet alle alle features ondersteunt, levert geen foutmeldingen op, je krijgt gewoon de indruk dat de restore is gelukt: Dat dit niet zo is, dat is weer jouw probleem. En er zitten verschillen in minor versions, die moet je dus maar net kennen.

MySQL is een no-go, ook voor webapplicaties. Het is vooral veel te kostbaar, ook voor een "gratis" product. Zelfs de licentiekosten van SQL Server zijn lager dan de ontwikkel- en testkosten van een applicatie voor MySQL... En PostgreSQL kost niks en levert wel betrouwbaarheid en performance.

MySQL heeft één pluspunt, iedere hostingprovider biedt het aan. Maar dat is dan ook het enige pluspunt. SQLite bieden ze ook aan, dat voldoet voor vele webapplicaties al.

[defcon84]

* Moet ik mijn access-databank vervangen door een mysql databank?
Ja. Het is natuurlijk niet verplicht, maar er is geen enkele reden om bij een Access db te blijven.

* Moet ik PHP gebruiken in combinatie met een access-databank?
Nee. Maar als je je applicatie hebt geschreven in VB.NET waarom schrijf je je website dan niet in Asp.NET? (en dan heb je natuurlijk de logische keuze van MS SQL Server wat veel leuker werkt en waar je sneller mee programmeert. )

* Moet ik mijn project herschrijven in een andere programmeertaal, zodat ik gemakkelijker kan werken met een mysql-databank?
Nee, zoals hierboven vermeld kan .NET perfect overweg met allerhande databases.

[Verwijderd]

HuHu schreef op dinsdag 22 juni 2010 @ 08:40:
Komt het überhaupt op dezelfde server te draaien? Meestal draait een applicatie voor facturatie en voorraad intern binnen een bedrijf en een website draait op een externe webserver. Dan is het sowieso niet handig om dezelfde database server te gebruiken, dus dan ben je ook direct niet meer gebonden aan het gebruik van dezelfde database server software.

Je moet dan wel synchroniseren (wellicht eenzijdig).

De website en de databank zullen op dezelfde server gehost worden.
Stel dat het niet zo is, om de hoeveel tijd zou ik dan moeten synchroniseren?

cariolive23 schreef op dinsdag 22 juni 2010 @ 09:18:
Access is snel om te zetten naar SQL Server (Express versie is gratis), dat is een echte database en zeker een factor 100 beter en betrouwbaarder dan MySQL. SQL Server is ook eenvoudig via PHP te benaderen, geen enkel probleem, zie de PHP handleiding.

Het nadeel van deze gratis versie is wel dat er een aantal beperkingen opgelegd worden. Zo kan mag mijn database bij de express-versie slechts 4GB groot worden. (ik weet niet hoe groot databases doorgaans zijn)

HuHu schreef op dinsdag 22 juni 2010 @ 10:56:
Ik zie eerlijk gezegd geen problemen als je gewoon de nieuwste versie neemt (MySQL 5.1) en eenvoudige dingen er mee doet. Dat je in veel applicaties fouten vind zegt misschien meer over de programmeurs van die applicaties dan de gebruikte database.

De voordelen van MySQL zijn dusdanig groot, zeker voor webapplicaties, dat je beter daar voor kunt kiezen.

Op school leerde ik ook werken met MySQL, en ook hier kwam ik nooit eerder problemen tegen.

cariolive23 schreef op dinsdag 22 juni 2010 @ 12:19:
[...]

MySQL is een no-go, ook voor webapplicaties. Het is vooral veel te kostbaar, ook voor een "gratis" product. Zelfs de licentiekosten van SQL Server zijn lager dan de ontwikkel- en testkosten van een applicatie voor MySQL... En PostgreSQL kost niks en levert wel betrouwbaarheid en performance.

Valt de combinatie VB.NET & PostgreSQL aan te raden?

defcon84 schreef op dinsdag 22 juni 2010 @ 14:11:
* Moet ik mijn access-databank vervangen door een mysql databank?
Ja. Het is natuurlijk niet verplicht, maar er is geen enkele reden om bij een Access db te blijven.

Dat ik van die access-databank moet afstappen is duidelijk, maar welke database kies ik in de plaats?

defcon84 schreef op dinsdag 22 juni 2010 @ 14:11:
* Moet ik PHP gebruiken in combinatie met een access-databank?
Nee. Maar als je je applicatie hebt geschreven in VB.NET waarom schrijf je je website dan niet in Asp.NET? (en dan heb je natuurlijk de logische keuze van MS SQL Server wat veel leuker werkt en waar je sneller mee programmeert. )

Op school leerden we PHP, en ik denk dat dit voor mijn toepassing ook mogelijk moet zijn. Zoals Cariolive123 al zei: PHP werkt ook in combinatie met MSSQL.

defcon84 schreef op dinsdag 22 juni 2010 @ 14:11:
* Moet ik mijn project herschrijven in een andere programmeertaal, zodat ik gemakkelijker kan werken met een mysql-databank?
Nee, zoals hierboven vermeld kan .NET perfect overweg met allerhande databases.

Maar dewelke?

• MySQL
• MSSQL Express
• PostgreSQL

[cariolive23]

Verwijderd schreef op dinsdag 22 juni 2010 @ 14:40:
Maar dewelke?

• MySQL
• MSSQL Express
• PostgreSQL

Hoe groot is/wordt jouw database? Wanneer nu Access al voldoet, zal SQL Server Express ook voldoen. Access kan (bij mijn weten) niet meer dan 1GB aan, met SQL Server Express kun je dus al 4GB aan. Daarnaast kun je altijd de licentie upgraden naar een versie die geen/minder beperkingen kent, afhankelijk van de hoeveelheid geld die jij/jouw opdrachtgever er in wil steken.

PostgreSQL voldoet uitstekend, kan prima via .NET worden gebruikt, is gratis en kent geen beperkingen. PostgreSQL en SQL Server kunnen ook prima samenwerken, ik ken situaties waarbij PostgreSQL wordt gebruikt voor replicatie van de data: Scheelt weer in de licentiekosten

MySQL is alleen handig wanneer betrouwbaarheid geen enkele rol speelt en jouw code bij iedere 1-euro-hostingprovider moet kunnen draaien.

[Verwijderd]

cariolive23 schreef op dinsdag 22 juni 2010 @ 14:58:
[...]

Hoe groot is/wordt jouw database? Wanneer nu Access al voldoet, zal SQL Server Express ook voldoen. Access kan (bij mijn weten) niet meer dan 1GB aan, met SQL Server Express kun je dus al 4GB aan. Daarnaast kun je altijd de licentie upgraden naar een versie die geen/minder beperkingen kent, afhankelijk van de hoeveelheid geld die jij/jouw opdrachtgever er in wil steken.

PostgreSQL voldoet uitstekend, kan prima via .NET worden gebruikt, is gratis en kent geen beperkingen. PostgreSQL en SQL Server kunnen ook prima samenwerken, ik ken situaties waarbij PostgreSQL wordt gebruikt voor replicatie van de data: Scheelt weer in de licentiekosten

MySQL is alleen handig wanneer betrouwbaarheid geen enkele rol speelt en jouw code bij iedere 1-euro-hostingprovider moet kunnen draaien.

De databank zal niet zo heel groot worden denk ik. Het wordt een product voor KMO's, dus ik denk dat ik al geen 100 000 klanten of 100 000 artikels zal moeten opslaan.

De software en website zal op een eigen server gehost worden, dus ook dat is het probleem niet.

[cariolive23]

Dan valt MySQL dus af, hou je SQL Server Express en PostgreSQL over.

Ik vermoed dat SQL Server Express een iets betere integratie heeft met .NET, maar het is beperkt tot 4GB. Voor grotere databases kan het kostbaar worden, zoek dat dus even uit. PostgreSQL kent geen beperkingen en kost niets.

Wat is voor jou belangrijker en welke $$$-risico's loop je wanneer de 4GB-grens een probleem is?

Ik zou voor PostgreSQL gaan, maar dat is dan ook m'n werk

[HuHu]

Ik vind dat je nogal overdrijft cariolive23. Je kunt er prima mee werken, het zorgt echt niet voor de vele problemen die jij schetst en het wordt overal en nergens gebruikt (ook misbruikt, maar je mag het product niet de schuld geven van mensen die er niet mee om kunnen gaan). Verder is het betrouwbaar zat, vele grote sites draaien op MySQL (zoals Tweakers of FOK!).

Maargoed... in je laatste post geef je ook al aan dat je niet objectief bent.

[cariolive23]

HuHu schreef op dinsdag 22 juni 2010 @ 15:34:
Ik vind dat je nogal overdrijft cariolive23.

Je kunt er prima mee werken, het zorgt echt niet voor de vele problemen die jij schetst en het wordt overal en nergens gebruikt (ook misbruikt, maar je mag het product niet de schuld geven van mensen die er niet mee om kunnen gaan). Verder is het betrouwbaar zat, vele grote sites draaien op MySQL (zoals Tweakers of FOK!).

Aantallen gebruikers en betrouwbaarheid hebben niets met elkaar te maken. Kwaliteit heeft er ook niets mee te maken, gebruikers maken zich pas druk over kwaliteit wanneer het te laat is. Wanneer een product fouten in de hand werkt, geef ik het product de schuld en niet de gebruiker/programmeur die een fout maakt. Fouten maken is menselijk, het is dus wel zo handig dat je een systeem gebruikt die jou helpt om deze te voorkomen en/of op te sporen. Vrijwel alle databases doen dat, behalve MySQL... Tot je MySQL fatsoenlijk gaat configureren, dan wordt het ook al een ander verhaal, brengt 9 van de 10x ook al vele bugs in code aan het licht. Maar nog steeds niet alles. En dat is gewoon een foute keuze van MySQL, die geeft liever foute resultaten dan een foutmelding naar de programmeur.

Maargoed... in je laatste post geef je ook al aan dat je niet objectief bent.

Niet objectief, maar ik ken MySQL wel veel te goed. Na 7 jaar weet je wel van de hoed en de rand, weet je waar je het over hebt. Dat is ook precies de reden waarom ik geen mens MySQL zou aanraden, het kost je altijd meer tijd om iets goeds voor MySQL te bouwen dan wanneer je dit voor bv. PostgreSQL of SQL Server zou bouwen: Fouten in je SQL komen direct aan het licht en niet pas tijdens het testen of in de productie. Dat is gewoon veel te laat en totaal overbodig.

Gebruik gewoon SQLite wanneer je maar een klein simpel databeestje nodig hebt en gebruik een betrouwbare DBMS wanneer je serieus aan de slag moet met een database.

My 2 cents

[JaQ]

Waarom wordt één technische oplossing uitgekouwd, terwijl de eerste primaire vragen niet beantwoord zijn? Deze vragen zijn o.a.:

• is het verstandig om het voorraadsysteem aan het internet te knopen?
• wil (en kan) de TS veel veranderen aan het originele systeem?
• is het huidige systeem bereikbaar te makenvia internet?

Gezien de ervaring van de TS en de (on)zekerheid waarmee gehandeld wordt, zou ik niet direct er voor kiezen om de kern van de bedrijfsvoering (klinkt wat zwaar, maar dat is het wel) online te plaatsen. De kans op een foutje in de webshop met als gevolg een afwezige administratie is evident lijkt me? Maar wellicht dat de TS hier anders over denkt?

Tevens zou ik voorzichtig zijn met het wijzigen van het huidige systeem. Het doet immers wat het moet doen, bestaande functionaliteit wijzigen kan voor onverwachte resultaten zorgen. Compleet herschrijven lijkt me onzinnig, tenzij je het geheel wil transformeren in een online applicatie (= andere functie). TS: wil je de applicatie transformeren, of ben je eigenlijk tevreden met de huidige applicatie?

Dit soort vraagstukken gaan m.i. dus niet over techniek


Mocht je gaan kiezen voor een andere database dan access: iedere database heeft voor en nadelen. Persoonlijk vind ik zowel MySQL als sql-server als postgressql niet geschikt voor een serieus systeem, maar dat komt vermoedelijk door mijn beperkte ervaring en mijn definitie van een serieus systeem .

[Verwijderd]

JaQ schreef op dinsdag 22 juni 2010 @ 16:01:
Waarom wordt één technische oplossing uitgekouwd, terwijl de eerste primaire vragen niet beantwoord zijn? Deze vragen zijn o.a.:

• is het verstandig om het voorraadsysteem aan het internet te knopen?
• wil (en kan) de TS veel veranderen aan het originele systeem?
• is het huidige systeem bereikbaar te makenvia internet?

Gezien de ervaring van de TS en de (on)zekerheid waarmee gehandeld wordt, zou ik niet direct er voor kiezen om de kern van de bedrijfsvoering (klinkt wat zwaar, maar dat is het wel) online te plaatsen. De kans op een foutje in de webshop met als gevolg een afwezige administratie is evident lijkt me? Maar wellicht dat de TS hier anders over denkt?

Tevens zou ik voorzichtig zijn met het wijzigen van het huidige systeem. Het doet immers wat het moet doen, bestaande functionaliteit wijzigen kan voor onverwachte resultaten zorgen. Compleet herschrijven lijkt me onzinnig, tenzij je het geheel wil transformeren in een online applicatie (= andere functie). TS: wil je de applicatie transformeren, of ben je eigenlijk tevreden met de huidige applicatie?

Dit soort vraagstukken gaan m.i. dus niet over techniek


Mocht je gaan kiezen voor een andere database dan access: iedere database heeft voor en nadelen. Persoonlijk vind ik zowel MySQL als sql-server als postgressql niet geschikt voor een serieus systeem, maar dat komt vermoedelijk door mijn beperkte ervaring en mijn definitie van een serieus systeem .

Het voorraadsysteem zal enkel gekoppeld worden om te controleren of het artikel nog op voorraad is. Er worden geen aanpassingen gedaan. Eventueel zal er nog een tabel bijkomen 'bestellingen' waarbij de gebruiker een bestelling over het internet kan plaatsen die wordt opgeslagen in de databank. Pas wanneer de producten verzonden zijn, wordt de voorraad herrekend.

Het project is gewoon een eindwerk, dat ik tegen begin juni af moest hebben. Ik zou er in de zomervakantie gewoon even mee willen door doen, om te kijken wat nu precies de mogelijkheden zijn. Wat kan ik al maken, zonder dat het mij iets kost, maar wat toch nog redelijk wat van nut heeft ...
Momenteel is er nog geen enkel bedrijf die deze applicatie gebruikt, dus alles wat (momenteel) op het internet komt te staan zullen testgegevens zijn. Pas wanneer er voldoende getest is, zal het programma eventueel aan derden worden gegeven.

Ik ben tevreden met de huidige applicatie, maar ik wil gewoon wat extra functionaliteiten toevoegen. Momenteel is het een klein programmaatje waarmee je enkel de stock kan bijhouden en facturen kan aanmaken.
Nu wil ik dit programma koppellen aan een webshop.


De eisen die ik nog stel aan de databank zijn:

• Relaties moeten gelegd kunnen worden
• Sessions
• Concurrencybeheer (COMMIT, ROLLBACK, ...)

Kan elk van bovenstaande databanken hiermee overweg?

[ Voor 86% gewijzigd door Verwijderd op 22-06-2010 16:09 ]