Bestaande tabellen overpompen naar MySQL

[chicky]

Hoi,

Bij het bedrijf waar ik werk hebben we een crm programma wat nog onder dos werkt . Het programma (zal de naam niet noemen) is in de loop der jaren uitgebreid met custom menu's, taken, opties, enz. enz. Het oorspronkelijke programma deed alleen relatie beheer, maar nu zit ALLES er in (document managment, voorraad beheer, bestel formulieren, uren registratie, calculatie methodiek enz. enz.)

De data van het programma wordt opgeslagen in losse bestanden met de extentie dbf (circa 85 bestanden, varierend van 1Kb tot 25 Mb)

In de tabellen zitten een soort van ID velden, welke in andere tabellen weer terug komen (relaties), soms zijn er wel 12 van deze ID velden per tabel.


Nu ben ik aan het onderzoeken om de functionaliteit van het programma over te zetten in een webbased database applicatie met apache, PHP en MySQL, met behoud van de data.

De vraag is, wat is slim ??

- Alle data met hand (of met een scriptje) in MySQL te importeren en dan de relaties met de hand weer aan elkaar te knopen.
- De bestaande ID velden (velden zijn niet auto-increment, maar random integer van wel soms wel 12 cijfers groot) laten bestaan, of MySQL nieuwe ID velden aan laten maken? (wel er voor zorgen dat de realties tussen tabellen niet verloren gaan natuurlijk)
- Kan MySQL zelf (na wat input natuurlijk) de relatie leggen tussen velden met een gelijke naam, welke in verschillende tabellen staan ?, of zijn hier speciale appz voor?
- Wat is voor een database met zo'n omvang qua tabellen een slimme opmaak? tabellen in één grote db dumpen of de db opdelen?

Ik denk aan MySQL, maar het kan ook een andere db worden. Staat nog niet vast.
Het gaat ook niet om de db, maar om de methodiek die vooraf moet gaan aan dit alles.

Graag wat commentaar.

[ Voor 0% gewijzigd door chicky op 14-09-2006 16:58 . Reden: typo's ]

[Siliakus]

Ik zou een professional laten komen om deze klus op te knappen.

a> Ik krijg het idee dat het gaat om een behoorlijk verouderd en toch (schijnbaar) onmisbaar programma. b> Aan de vragen die je stelt is ook te zien dat je zelf weinig tot geen ervaring hebt met gegevens-migraties.

Dit gecombineerd maakt dat ik denk dat je het beter niet zelf kan doen. No offence natuurlijk.

[Verwijderd]

Zou eerst 's ff die DB reverse engineren, zijn zat tools die die .dbf (dbase) bestanden kunnen inlezen.
Kan je daarna op je gemak de relaties visualiseren etc.
Vervolgens kan je exporteren naar een verscheidenheid aan database formaten (sql scripts).
Sommige van deze tools kunnen ook de data voor je overzetten (datapump).

Echter hebben jullie de sourcecode van die software ?
Je zal dan ook een lijstje moeten maken van de huidige functionaliteit en allerlei
zaken uit de contraints en logica uit de oude code moeten extraheren.

Indien dit een complex pakket is (zo te lezen zit er aardig wat functionaliteit in), ben je er
wel ff zoet mee.

Misschien handig om ook rond te kijken of de bestaande functionaliteit niet door standaard software
kan worden geïmplementeerd.

[MBV]

Hmm, klinkt zo'n beetje als het bedrijf waar ik werk. Alleen is daar besloten om het CRM-pakket te laten bestaan, en alleen de meest voorkomende zaken in een aparte database te zetten. Oh ja, het pakket werkt al (zij het op een bijzondere manier) met MSSQL, dat helpt.

Wat ik zou doen, als een expert inhuren geen optie is, is het programma zelf de gegevens laten exporteren. Op die manier krijg je geen problemen met vage dingen in het databaseformaat. Ook is het handig om uit te zoeken of .dbf niet perongeluk toch een standaard is, wat erg makkelijk zou zijn

[RobIII]

MBV schreef op donderdag 14 september 2006 @ 19:30:
Wat ik zou doen, als een expert inhuren geen optie is, is het programma zelf de gegevens laten exporteren. Op die manier krijg je geen problemen met vage dingen in het databaseformaat. Ook is het handig om uit te zoeken of .dbf niet perongeluk toch een standaard is, wat erg makkelijk zou zijn

.dbf is een (well known) standaard DBase

Ik vermoed, gezien het verhaal van de TS, dat de huidige applicatie geen 'export de hele meuk maar naar een leuk formaatje' optie heeft Maar het moet geen probleem zijn om .dbf-jes in te lezen en te converteren naar willekeurig welke andere gangbare DB.

[ Voor 31% gewijzigd door RobIII op 14-09-2006 19:37 ]

[MBV]

Dat had de TS dan nog niet door, als ik het goed heb gelezen.

Over het "exporteer de hele meuk" gedoe: dan bouw je dat toch zelf? Vaak maakt legacy software gebruik van smerige hacks om ints in VARCHAR kolommen te gooien voor FK's of andere gein van die orde. Als je het uit de database trekt zal je dat misschien over het hoofd zien.

[chicky]

MBV schreef op donderdag 14 september 2006 @ 21:03:
Dat had de TS dan nog niet door, als ik het goed heb gelezen.

Over het "exporteer de hele meuk" gedoe: dan bouw je dat toch zelf? Vaak maakt legacy software gebruik van smerige hacks om ints in VARCHAR kolommen te gooien voor FK's of andere gein van die orde. Als je het uit de database trekt zal je dat misschien over het hoofd zien.

Sorry de TS had het wel door.
De optie: export de hele meuk bestaat niet.

doordat er aan het bestaande programma extra functialiteit is toegevoegd, zonder dat de door de ontwikkelaar goed over na is gedacht (hebben ze zelf toegegeven), is de data niet op een strucurele wijze gekoppeld/verweven met de "oude" data. Ze hebben er gewoon een tabelletjes bij gehangen met een aantal relaties.

Zoals ik al zei bestaan in sommige tabellen (ik heb ze nog niet allemaal door gekeken) wel 12 verwijzingen naar ID velden in andere tabellen, dat gecombineerd met zo'n 80 tabellen, maakt nogal wat relaties tussen tabellen.
Vandaar het probleem met data export naar een nieuwe database.

[chicky]

Verwijderd schreef op donderdag 14 september 2006 @ 19:11:
Zou eerst 's ff die DB reverse engineren, zijn zat tools die die .dbf (dbase) bestanden kunnen inlezen.
Kan je daarna op je gemak de relaties visualiseren etc.
Vervolgens kan je exporteren naar een verscheidenheid aan database formaten (sql scripts).
Sommige van deze tools kunnen ook de data voor je overzetten (datapump).

Echter hebben jullie de sourcecode van die software ?
Je zal dan ook een lijstje moeten maken van de huidige functionaliteit en allerlei
zaken uit de contraints en logica uit de oude code moeten extraheren.

Nee de source is niet voorhande. Er wordt nu nog steeds door de ontwikkelaar aanpassingen gemaakt in de app.

Indien dit een complex pakket is (zo te lezen zit er aardig wat functionaliteit in), ben je er
wel ff zoet mee.

Ja, dat weet ik.

Misschien handig om ook rond te kijken of de bestaande functionaliteit niet door standaard software
kan worden geïmplementeerd.

Er zijn gesprekken geweest met diverse software ontwikkelaars o.a. SAP en Exact.
De kosten voor het customize van de pakket die zij leveren zijn enorm en schieten (waarschijnlijk) het doel voorbij.

[chicky]

Oke,

Ik begrijp heel goed de omvang van het probleem.

Vraag :

Zijn er programma's waarmee ik de bestaande "database" opmaak (met name de relaties tussen de tabellen) goed en makkelijk van visualizeren. En kan ik na visualisatie en optimalisatie van de tabellen het gevisualiseerdde dan zo in een db pompen om daar de correcte tabel opmaak e.d. te krijgen.

[Verwijderd]

chicky schreef op donderdag 14 september 2006 @ 22:54:
[...]
Nee de source is niet voorhande. Er wordt nu nog steeds door de ontwikkelaar aanpassingen gemaakt in de app.

da's minder.

Wat je kan doen, als je de nieuwe DB heb opgezet (zie m;n vorige post), is een dump tool schrijven in VB(.net) of Delphi achtig iets, daar zijn dbf libraries voor, of via ODBC. (misschien ook in php ?)
Dan zet je de data klaar voor import in je nieuwe DB (eg MySql).

Ja, dat weet ik.

Ik ga ervanuit dat jullie zelf geen software house zijn en/of ontwikkelaars in dienst hebben ?
Zo niet, denk dan goed na voor dat je er aan begint. Huur in ieder geval in het begin stadium
iemand in die jullie op het goede spoor kan zetten.

Er zijn gesprekken geweest met diverse software ontwikkelaars o.a. SAP en Exact.
De kosten voor het customize van de pakket die zij leveren zijn enorm en schieten (waarschijnlijk) het doel voorbij.

Ja, dan noem je ook wat op
Zoek het is in de wat kleinere leveranciers, of laat eventueel een softwarehouse een vrijblijvende offerte opmaken.

[Verwijderd]

chicky schreef op donderdag 14 september 2006 @ 22:57:
Oke,

Ik begrijp heel goed de omvang van het probleem.

Vraag :

Zijn er programma's waarmee ik de bestaande "database" opmaak (met name de relaties tussen de tabellen) goed en makkelijk van visualizeren. En kan ik na visualisatie en optimalisatie van de tabellen het gevisualiseerdde dan zo in een db pompen om daar de correcte tabel opmaak e.d. te krijgen.

http://www.fabforce.net/dbdesigner4/

ben ik zelf nogal weg van.
Als het goed is kan je via ODBC dan je dbase tabellen inlezen, om reverse te engineeren.

Voor het overpompen v/d data zie m'n vorige post, denk dat het wat te complex is voor pakketen om dit standaard te doen.

[ Voor 9% gewijzigd door Verwijderd op 14-09-2006 23:05 ]

[joepP]

Waarom moet de applicatie herschreven/gemigreerd worden naar een nieuw platform?

Verder lijkt het mij een kantoorapplicatie, waarom heb je het idee dit webbased te willen doen? De kosten voor het ontwikkelen van een standaard applicatie waarmee mensen de hele dag werken is vaak vele malen lager als je voor specifieke software kiest, misschien iets van C#, MSSQL en een fatsoenlijke O/R mapper. Of een java-based oplossing.

[chicky]

De ontwikkelaar heeft aangegeven op niet al te lange termijn een "nieuwe" windows- versie van het pakket uit te geven, zonder het custom deel wat wij hebben en geen verder uitbereiding aan het pakket wat wij hebben te willen doen.
Het customize van het nieuwe pakket brengt weer enorme kosten met zich mee.

Tevens is het zo dat het huidige pakket totaal niet mee voldoet aan de huidige gebruiks eisen (40 gebruikers die 1 executable runnen vanaf de server ) en allerlei foutmeldingen die voorbij komen in dagelijks gebruik.

Vandaar de zoek naar een nieuw pakket.

Het idee van een webbassed app. is omdat in het pakket bijna niets anders wordt gedaan dan schrijven naar en lezen van database gegevsn.
Onwikkeling in een webbassed omgeving is zeer flexibel en relatiev goedkoop en met kijk op de toekomst platform onafhankelijk en goed voor thuiswerkers.

Natuurlijk zitten er ook nadelen aan webbassed appz. dat begrijp ik, maar ik denk dat een stap in die richtingf op lange termijn niet geheel onzin is.

Keuze voor een standaard applicatie zal betekenen dat ruim 15 jaar bedrijfsstructuur op z'n gat moet, (samen met 40 binnen en circa 100 buitenmedewerkers). Ik denk dat het customize van de software dan een betere oplossing is.

[Verwijderd]

chicky schreef op vrijdag 15 september 2006 @ 14:34:
De ontwikkelaar heeft aangegeven op niet al te lange termijn een "nieuwe" windows- versie van het pakket uit te geven, zonder het custom deel wat wij hebben en geen verder uitbereiding aan het pakket wat wij hebben te willen doen.
Het customize van het nieuwe pakket brengt weer enorme kosten met zich mee.

Hebben jullie wel een offerte hiervoor aangevraagd bij de ontwikkelaar ?

Tevens is het zo dat het huidige pakket totaal niet mee voldoet aan de huidige gebruiks eisen (40 gebruikers die 1 executable runnen vanaf de server )

Is niet zo'n probleem lijkt me, zie je meer.
Is eerder de onderliggende DB die nu een probleem vormt waarschijnlijk (of kan vormen).

en allerlei foutmeldingen die voorbij komen in dagelijks gebruik.

Ontwikkelaar geeft geen support meer ?

Het idee van een webbassed app. is omdat in het pakket bijna niets anders wordt gedaan dan schrijven naar en lezen van database gegevsn.
Onwikkeling in een webbassed omgeving is zeer flexibel en relatiev goedkoop en met kijk op de toekomst platform onafhankelijk en goed voor thuiswerkers.

Vergis je niet in tijd en kosten om een geheel maatwerk pakket te schrijven, of het nu webbased is of in een taal als C#,VB.Net, Delphi oid.

Natuurlijk zitten er ook nadelen aan webbassed appz. dat begrijp ik, maar ik denk dat een stap in die richtingf op lange termijn niet geheel onzin is.

Keuze voor een standaard applicatie zal betekenen dat ruim 15 jaar bedrijfsstructuur op z'n gat moet, (samen met 40 binnen en circa 100 buitenmedewerkers). Ik denk dat het customize van de software dan een betere oplossing is.

[/quote]
Denk toch dat het verstandiger is om wat meer onderzoek te doen wat er zoal op de markt is, en wat het beste aansluit bij jullie wensen.
Veel software van tegenwoordig (ook de kleinere pakketen) kun je vrij veel customizen door inrichten etc.

[MBV]

Kijk ook even naar open-source pakketten. Er zijn namelijk al mensen die CRM-achtige dingen open-source hebben gemaakt Zoiets customizen is vaak goedkoper dan opnieuw beginnen.

Als je het zelf maakt, houd er dan rekening mee dat het vooral onderhoudbaar moet zijn. Gewoon even snel in elkaar hacken gaat je veel meer tijd kosten. Dus huur een body-guard (a.k.a. manager) in om de vervelende interne klanten van je lijf te houden terwijl jij ontwerp maakt, en voor een degelijke implementatie zorgt. Een applicatie die na een half jaar voor 90% af is, en na 3 jaar nog niet voor 100%, is een veel vervelendere applicatie dan een die na een jaar 100% af is

[Verwijderd]

chicky schreef op donderdag 14 september 2006 @ 22:57:
Zijn er programma's waarmee ik de bestaande "database" opmaak (met name de relaties tussen de tabellen) goed en makkelijk van visualizeren.

Kort en bondig: nee.
dBase/Clipper/Foxpro databases hebben zelf geen notie van relaties tussen de verschillende tabellen, en hebben geen idee wat foreign keys zijn. De database zelf is niks meer dan een stel bestanden waar de tabellen in staan (.dbf), en een aantal bestanden voor de indexen (.idx, .sdx, .ntx, etc.). Alle relaties worden door de client(s) beheerd en onderhouden.

[MBV]

ga eens babbelen met wat automatiseerders. Dikke kans dat ze al een keer een transitie hebben moeten doen voor iemand, en dus al het schema kennen.

En anders wordt het debuggen met een lege database en gegevens toevoegen

[ Voor 6% gewijzigd door MBV op 16-09-2006 11:35 ]

[Olaf van der Spek]

Bestaande tabellen overpompen naar MySQL

Als ik dit topic zo lees vraag ik me af of dit niet een van de kleinere zorgen is.
Een complete applicatie ontwikkelen is veel en veel complexer dan even wat data overpompen.

[chicky]

Begrijp ik ook wel.

Een van de problemen is het overpompen van data.

Of een applicatie wordt gekocht/gemaakt/geleend of wat dan ook, het overpompen van de data naar een gestructureerde omgeving zal altijd blijven bestaan. Vandaar de oorspronkelijke vraagstelling.

[BCC]

Gaat dit om een motorbedrijf?

[chicky]

NEE

(maar vanwaar deze vraag?)

Ik ken niet één motorbedrijf met 40 man binnen en circa 100 man in een buitendienst functie.

[ Voor 59% gewijzigd door chicky op 18-09-2006 22:18 ]

[BCC]

Dat heb je nog niet eerder gezegd. Maar ik vraag het omdat ik laatst bij een migratie traject van een motorzaak ben betrokken waarbij ook nog met een oude DBase app werd gewerkt. Ik zag veel overeenkomsten

[ Voor 15% gewijzigd door BCC op 18-09-2006 22:20 ]

[djluc]

Is je data nog wel geheel consistent? Oftwel: Kloppen die gegevens die er nu instaan eigenlijk wel, zijn ze allemaal op de juiste manier ingevoerd enzovoorts?

[chicky]

Niet in alle gevallen is de data consistent.

voorbeeld:
aan een relatie hangt een projecten, aan het project hangt urenregistratie.
Nu is in een aantal gevallen en relatie verwijderd, hierdoor zijn de bijbehorende projecten en urenregistratie niet (via de normale procedure) terug te vinden.

Ik heb een deel van de data gecontroleerd op dit soort problemen, maar nog niet alles.

Ik zit te denken om de data niet te exporten/importen, maar geheel opnieuw op te bouwen. Nieuwe relaties leggen op basis van de huidige, aantal tabellen sterk verminderen, nieuwe ID velden aanmaken enz. enz.
Is nog wel wat werk, maar dan heb je ook wat.

[Gerco]

chicky schreef op maandag 18 september 2006 @ 22:09:
Of een applicatie wordt gekocht/gemaakt/geleend of wat dan ook, het overpompen van de data naar een gestructureerde omgeving zal altijd blijven bestaan. Vandaar de oorspronkelijke vraagstelling.

Voor je gaat pompen, zul je toch moeten weten naar welk formaat je dat wilt doen. Als je de data in een bepaald formaat in een andere database hebt staan, moet je nog een pakket hebben wat daarmee kan omgaan (of wilde je soms alles in PHPMyAdmin gaan doen?).

Kies je voor pakket 1, zul je een hele andere conversie gaan doen dan wanneer je voor pakket 2 kiest. Beide pakketten zullen een hele andere manier van nadenken en opslaan hebben. Voor je zelfs maar over je conversie gaat nadenken zul je moeten beslissen wat die conversie moet gaan doen (naar welk pakket dus).

Als je een pakket koopt of huurt van een derde partij, zou ik die partij erbij betrekken aangezien ze waarschijnlijk hun support zullen opzeggen zodra je zelf in de database gaat rommelen. Ga je zelf een pakket maken, schrijf dan eerst je pakket en converteer dan pas je data. Anders krijg je een legacy pakket in een webbased jasje en ben je nog net zo ver van huis als nu.

Is nog wel wat werk, maar dan heb je ook wat.

Dan heb je een collectie tabellen met data, maar geen software die er iets zinnigs mee kan. Wat je dan hebt is dus waardeloze rommel en flink wat verloren tijd.

- Wat is voor een database met zo'n omvang qua tabellen een slimme opmaak? tabellen in één grote db dumpen of de db opdelen?

Een database van 85x 25MB (worst case) is niet heel erg klein (zo'n 2GB), maar voor elk modern dbms (ook MySQL) geen enkel probleem. Performance hoef je je geen zorgen over te maken en opsplitsen van je db zou ik niet eens aan *denken* tenzij je daar een functionele reden voor hebt.

[ Voor 19% gewijzigd door Gerco op 21-09-2006 12:00 ]

[Verwijderd]

Dit soort zaken komt steeds vaker voor. Veel bedrijven wachten echter veel te lang met het upgraden / aanpassen van dit soort dingen.

Bij mijn huidige stagebedrijf speelt zich precies het zelfde af (maar dan op een nog grotere schaal). Anno 2006 zijn ze er achter gekomen dat het misschien makkelijk is om vanuit de productielijn direct de data op te slaan in een database, in plaats van dat de werknemers alle informatie invult op formulieren, etiketten met de hand schrijft en de administratie de hele boel invoert in een database.
En als ze dan toch modern bezig zijn, dan moeten de verkopers voortaan ook de voorraad digitaal kunnen zien.

De database is geen enkel probleem hier (behalve de achterlijk grote omvang ), een veel groter probleem is de software die functionaliteit moet bieden aan veel verschillende doelgroepen (productiemedewerkers, administratie, management, verkopers, etc.). Zelfs met de hulp van een bedrijf (die de boel met behulp van Navision ) op poten probeert te krijgen, is dit een klus die zeer veel werk en tijd met zich meebrengt.

Ik hoop dat je je realiseert dat het consistent maken van je database één probleem is, maar dat je het tweede probleem van de software die de database gebruikt niet onderschat.

[djluc]

Als je database niet eens echt goed consistent is zou het zeker een analyse van de kosten waard zijn om er in 1x voor te zorgen dat je data geheel klopt. Of het rendabel is moet je berekenen, vergeet daarbij niet de kosten welke ontstaan door het feit dat de software moet werken met een db welke niet consistent is.

[Scoutertje]

Verwijderd schreef op vrijdag 15 september 2006 @ 20:33:
Kort en bondig: nee.
dBase/Clipper/Foxpro databases hebben zelf geen notie van relaties tussen de verschillende tabellen, en hebben geen idee wat foreign keys zijn. De database zelf is niks meer dan een stel bestanden waar de tabellen in staan (.dbf), en een aantal bestanden voor de indexen (.idx, .sdx, .ntx, etc.). Alle relaties worden door de client(s) beheerd en onderhouden.

dBase en Clipper wil ik af zijn, maar FoxPro heeft al sinds versie 3 een echt databaseformaat
waarin relaties, triggers en referential integrity etc. kunnen worden geregeld. Inmiddels zijn we
bij versie 9...