[Analyse] Oplossingen

[Verwijderd]

Ik moet een nieuw uitgebreide toepassing schrijven voor een onderneming en wou bij het aanbieden van de oplossingen zou ruim mogelijk een voorstelling geven, maar ik word een beetje beïnvloed door mijn eigen voorkeur om Webbased in PHP met mySQL te werken.

Het gaat om een toepassing die gegevens van 3 vestigingen in België moet centraliseren.
Vele gegevens moeten ongeveer twee jaar bijgehouden worden (aankoop, verkoop, ... ) om statistisch
gegevens te kunnen bekomen.

EDIT:
Er zullen maximum 20 gebruikers tegelijk mee bezig zijn.
En in totaal misschien 50 gebruikers.

Mijn analyse ziet er verkort als volgt uit:

!! Analyse is AANGEPAST verder in deze TOPIC !!
http://gathering.tweakers.net/forum/list_messages/1012852/1

!! Oplossing toegevoegd !!

> Oracle Forms :
Pro: Geen opleiding nodig
Con: Duur in aanschaf
Con: Weinig en dure support

> Progress :
Pro: Duur in aanschaf maar reeds in bezit
Con: Opleiding nodig
Con: Duur in opleiding
Con: Weinig en dure support

> Webbased :
Codering : ASP(HTML/XML/CSS/JS)
Database : MSSQL

Pro: Geen opleiding nodig
Pro: Enorm veel support wegens populariteit
Pro: Iedereen heeft een browser, geen software installeren.
Con: Duur (maar goedkoper dan Progress)

> Webbased :
Codering : PHP(HTML/XML/CSS/JS)
Database : mySQL

Pro: Geen opleiding nodig
Pro: Enorm veel support wegens populariteit
Pro: Gratis (met uitzondering van hardware structuur)
Pro: Snelle database
Pro: Iedereen heeft een browser, geen software installeren.
Con: Beperkte database (geen triggers / stored procedures)


Zijn er zaken die ik over het hoofd heb gezien? Wat is er nog belangrijk om rekening me te houden bij de ontwikkeling van een nieuwe toepassing. Ik hoor het graag. Liefst van mensen met ervaring.

Ik heb VB weggelaten ... is dat een grove inschattingsfout van deze programmeertaal of niet?
Ik ben vertrouwd met alle bovenstaanden (en ook VB) programmeeromgevingen (met uitzondering van Progress)

[ Voor 12% gewijzigd door Verwijderd op 04-03-2005 08:45 . Reden: Aangepaste analyse ]

[Dennis]

Als triggers en stored procedures een eis zijn dan kun je ook overwegen om php en postgresql te gebruiken.

Visual Basic.NET beschouw ik als een volledige programmeertaal en is voor dit soort toepassingen prima te gebruiken. Je zult dan wel met MSSQL (of een andere relationele database) moeten werken want ik denk dat Access hier slecht geschikt voor is.

Over hoeveel gegevens gaat het eigenlijk?

[Verwijderd]

De huidige toepassing is ontworpen in Oracle Forms op een Oracle Database.
Gemaakt door een Duits bedrijf en is héél slecht genormaliseerd en bevat momenteel
ongeveer 280 tabellen waarvan ongeveer 30 % maar van gebruikt wordt.

Ik heb geen toegang tot de files van de database dus ik weet niet hoe groot die is.
Bestaat er een bruikbaar verband tussen de grootte van de database en de te
gebruiken database ? BVB mySQL tot 100MB en MSSQL tot 1GB ? (is maar een voorbeeld)

[Dutch_guy]

Als je bij MySQL het volgende neerzet:

Pro: Snelle database

Dan mag je dat zeker ook wel bij de Oracle en de MSSQL oplossing zetten.

[gorgi_19]

SQL Server kan rustig vele GB's aan; MySQL afaik ook. MSDE gaat niet meer dan 2 GB slikken; MS Access ook niet, maar vindt sowieso grote databases niet plezant

[P_de_B]

Je hebt 'snelle database' als pro staan bij MySQL, maar volgens mij zou je dat ook best bij SQL Server neer kunnen zetten.

Daarnaast zou ik zaken als referentiele integriteit en transacties ook mee laten wegen in de keuze van de database.

je hebt blijkbaar een vast combinatie PHP/MySQL en ASP/MSSQL. Je zou ook kunnen overwegen PHP/MSSQL te doen bijvoorbeeld.

[TukkerTweaker]

Verwijderd schreef op woensdag 23 februari 2005 @ 13:52:
De huidige toepassing is ontworpen in Oracle Forms op een Oracle Database.
Gemaakt door een Duits bedrijf en is héél slecht genormaliseerd en bevat momenteel
ongeveer 280 tabellen waarvan ongeveer 30 % maar van gebruikt wordt.

Ik heb geen toegang tot de files van de database dus ik weet niet hoe groot die is.
Bestaat er een bruikbaar verband tussen de grootte van de database en de te
gebruiken database ? BVB mySQL tot 100MB en MSSQL tot 1GB ? (is maar een voorbeeld)

Niet echt, in oracle kun je de grootte van de tablespace zelf defineren.
Maar als je al een huidige oracle database hebt dan zou ik daar zeker niet van afstappen. Wat je als client gebruikt licht aan je eigen voorkeur.

[Verwijderd]

Tuurlijk kan je met ASP en PHP heel wat schuiven en doen met de databases.

Maar ik hield de gratis PHP bij de gratis database mySQL.
En de prijzige IIS die je moet draaien voor ASP bij de niet gratis database MSSQL.
(beide tevens Microsoftproducten)

Alvast bedankt voor de typ van Postgress.. ik wist niet dat die stored procedures en triggers had.

[Verwijderd]

Er is ook PostgreSQL, een gratis database vergelijkbaar met MySQL. In het verleden had PostreSQL meer features dan MySQL, maar MySQL is bezig in te lopen.

www.postgresql.org

[Wolfboy]

P_de_B schreef op woensdag 23 februari 2005 @ 13:53:
je hebt blijkbaar een vast combinatie PHP/MySQL en ASP/MSSQL. Je zou ook kunnen overwegen PHP/MSSQL te doen bijvoorbeeld.

Nu weet ik niet wat de situatie bij de TS is (of de DB op een anders systeem komt of niet) maar als beiden op hetzelfde systeem komen dan heeft het niet veel nut om PHP/MSSQL te gebruiken aangezien je dan toch al een windows server hebt draaien.
ASP/MySQL lijkt me dan een goedkopere mogelijkheid.

Als vooral de kosten en triggers/stored procedures van belang zijn dan zou ik waarschijnlijk voor PHP/PostgreSQL gaan.

[Verwijderd]

Is mySQL door zijn beperkte mogelijkheden niet sneller dan MSSQL of Oracle.

(hoopt eigenlijk ook nog op een beetje input ivm Progress )

[P_de_B]

Verwijderd schreef op woensdag 23 februari 2005 @ 13:59:
Tuurlijk kan je met ASP en PHP heel wat schuiven en doen met de databases.

Maar ik hield de gratis PHP bij de gratis database mySQL.
En de prijzige IIS die je moet draaien voor ASP bij de niet gratis database MSSQL.
(beide tevens Microsoftproducten)

Alvast bedankt voor de typ van Postgress.. ik wist niet dat die stored procedures en triggers had.

IIS is niet zo prijzig hoor, kijk maar eens naar de Windows2003 web edition. Dat MSSQL duurder is dan mySQL klopt natuurlijk, maar zoals gezegd moet je dan ook op andere criteria proberen te beoordelen. Alles hangt natuurlijk af van de eisen die je stelt

Gezien het feit dat de huidige database Oracle is, en daar ws. ook licenties voor betaald zijn kun je ook ASP.NET/PHP met een Oracla database overwegen.

[Verwijderd]

Ook, dan ga ik mijn oplossingsbeoordeling best opsplitsen in Database en Programmeeromgeving

Zo kan er lekker gemixed worden en wordt het aanbod van oplossingen groter.
(altijd een + punt voor het management )

[P_de_B]

Verwijderd schreef op woensdag 23 februari 2005 @ 14:05:
Ook, dan ga ik mijn oplossingsbeoordeling best opsplitsen in Database en Programmeeromgeving

Goed zo!

(altijd een + punt voor het management )

Hier ben ik het niet zo mee eens, het is je werk een voorselectie te doen, en een met argumenten omkleed advies uit te brengen. Niet een opsomming van alle mogelijkheden.

[Verwijderd]

Ja, tuurlijk worden ze beoordeeld, alle oplossingen en zal ik met een eigen voorkeur naar voor komen. Maar een manager "de indruk" geven dat hij deze beleidsbeslissing "weloverwogen" genomen heeft is zowiezo een pluspunt

[Verwijderd]

Kan in Oracle Forms met een andere database gewerkt worden dan Oracle ?
Ik ken Oracle Forms maar ik heb daar altijd met een Oracle DB gewerkt en nooit iets anders.

En kan Progress met andere databases werken dan de Progress Database en kan
een Progress Database gebruikt worden voor bvb met PHP/VB/ASP te benaderen?

[whoami]

Moet je niet eerst te weten komen of je klant een webapplicatie wel ziet zitten, of dat hij niet liever een rich client app heeft ?

[P_de_B]

whoami schreef op woensdag 23 februari 2005 @ 14:13:
Moet je niet eerst te weten komen of je klant een webapplicatie wel ziet zitten, of dat hij niet liever een rich client app heeft ?

Dat zou denk ik een onderdeel van het advies zijn? De keuze tussen web of desktop.

[Janoz]

Ik neem aan dat ze al licenties op Oracle hebben gezien de huidige toepassing. Het lijkt me daarom ook niet geheel onlogisch om in je nieuwe systeem gebruik te maken van Oracle. Ook Oracle is wel via PHP en ASP aan te spreken. Dat lijken mij ook dingen om mee te nemen.

Daarnaast lijkt het me redelijk bedrijfskritische informatie. Die zou ik persoonlijk niet zo snel aan MySQL toekennen (wikipedia anyone). Dat lijkt me iig een heel belangrijk punt om mee te nemen in je overwegingen. Je wilt niet weten hoe duur verlorengegane data is. Daar kun je wel een paar Oracle licenties voor kopen.

[whoami]

Ik zou ook zowiezo de beslissende factor in de keuze niet de prijs laten zijn; zeker voor de DB.

Ik geloof dat de gegevens die moeten bewaard worden, wel belangrijk genoeg zijn voor het bedrijf om wat geld uit te geven aan een DB die garandeerd dat de gegevens consistent blijven.

Indien het een applicatie betreft waar vooral veel data input moet gedaan worden, zou ik -denk ik- zeker niet voor een webapplicatie gaan.

[markvt]

je kan ook eens naar postgresql (postgress) kijken ipv mysql. http://www.postgresql.org/

MySQL is vergeleken met postgresql een klein kind.

[ Voor 45% gewijzigd door markvt op 23-02-2005 14:24 ]

[Verwijderd]

Als het bedrijf al een Oracle database heeft staan lijkt het mij handig om in ieder geval een Oracle database aan te bieden. In dat geval hoeven ze namelijk niet te investeren in Oracle en ze weten dan wat ze krijgen. Daarnaast weet ik niet waarom je Progress wil aanbieden. Je hebt er namelijk geen verstand van. Dat zij een licentie hebben is leuk maar jou een cursus geven en je in laten werken is duurder dan welke licentie op een programmeertaal dan ook.

Daarnaast geef je eigenlijk maar heel summier aan wat voor applicatie het moet worden.
Iets moet gecentraliseerd worden. Ik neem aan dat je bedoeld dat de gegevens centraal bewaard moeten worden en de verschillende vestigingen over het internet bij die gegevens moeten kunnen. Een webinterface is dan een mogelijkheid maar je kan ook via een VPN doen alsof je op het locale lan zit en de huidige interface blijven gebruiken. Maar dat levert jou minder op dus vergeet dat maar weer snel
Voor webinterfaces heb je eigenlijk 3 keuzes, .PHP, NET en Java. Voordeel van de laatste twee is dat je er ook makkelijk een client mee kan maken die buiten de browser werkt en functioneert als los programma. De keuze is een beetje afhankelijk van wat je wilt bouwen. Wordt de interface complexer dan wordt PHP redelijk onhandig, maar jij hebt meer ervaring met PHP dan ik.

[ Voor 9% gewijzigd door Verwijderd op 23-02-2005 14:31 ]

[Verwijderd]

whoami schreef op woensdag 23 februari 2005 @ 14:19:

Indien het een applicatie betreft waar vooral veel data input moet gedaan worden, zou ik -denk ik- zeker niet voor een webapplicatie gaan.

Waarom valt dat dan af te raden ?

En hoe komt het dat die uitgebreide Postgress gratis is ? Wat is het addertje onder het gras ?

[Verwijderd]

Inderdaad ook Java heb ik blijkbaar buitenbeschouwing gelaten.
Niet tegenstaande dat ik daar ook al in ontwikkeld heb, maar nog niet met een database.

Deze moet er dus zeker ook nog in komen.

[Wolfboy]

Heb je eigenlijk ook al de voor- en nadelen van een webinterface bekeken?
Voordelen:

• Werkt overal zonder installatie
• Relatief snel en eenvoudig in elkaar te zetten

Nadelen:

• Voor het invoeren van gegevens wordt het automatiseren lastiger (realtime input validatie)
• Bij grote hoeveelheden data langzaam

Er zullen vast wel meer punten te noemen zijn maar deze punten lijken me wel handig om ook te overwegen.

[whoami]

Wolfboy schreef op woensdag 23 februari 2005 @ 14:43:
Heb je eigenlijk ook al de voor- en nadelen van een webinterface bekeken?
Voordelen:

• Werkt overal zonder installatie
• Relatief snel en eenvoudig in elkaar te zetten

Het 2de voordeel kan ook gelden voor rich clients, en het eerste voordeel kan ook gelden voor rich clients mits je een automatische update-procedure oid kunt maken.

[Verwijderd]

Wolfboy schreef op woensdag 23 februari 2005 @ 14:43:
Nadelen:

• Voor het invoeren van gegevens wordt het automatiseren lastiger (realtime input validatie)
• Bij grote hoeveelheden data langzaam

Realtime input validatie moet je toch ook uitvoeren bij niet webbased toepassingen?
En waarom gaat webbased trager ?

De centrale server zal voor enkele vestigingen verder staan dan de andere, wat een
vertraging zal opleveren, maar dat heb je bij een niet-webbased toepassing toch ook?

En dat sneller ontwikkelen, tjah, da's enkel maar een kwestie van voorkeuren hé Sommige mensen hebben sneller iets klaar in VB dan in een ASP script bvb.

[Morrar]

Verwijderd schreef op woensdag 23 februari 2005 @ 14:30:
[...]
En hoe komt het dat die uitgebreide Postgress gratis is ? Wat is het addertje onder het gras ?

Dat is er niet. Het is gewoon een heel erg strakke gratis database! Heb em een tijdje draaien hier onder WinXP (win wordt sinds kort native ondersteund) en het draait echt goed. Deze database heeft echt wat meer features dan MySQL:
- keurige implementatie van foreign keys (nog maar net in MySQL)
- keurige implementatie stored procedures (komt pas in MySQL 5)
- triggers + trigger functions (volgens mij nog niet in MySQL)
- domains + user defined operators etc (je kan zelf datatypen en operatoren definieren)
etc etc.

Alleen is de combi PHP + MySQL gewoon veel bekender, mede omdat veel hostingbedrijven het standaard installeren. Jammer wel, want PostgreSQL is echt beter. Maar er is dus geen addertje

[ Voor 6% gewijzigd door Morrar op 23-02-2005 15:01 ]

[Verwijderd]

Offtopic:
Nice to know, mijn hosting bedrijf bied Postgres, maar ik gebruik het nog niet, want ik heb de extra functies nog niet nodig. (www.sdhosting.nl)

Ontopic:
Ik heb net wat op het net gezocht op Progress en daar wordt wel eens van gezegd dat deze aan het doodbloeden is... Probleem is dat het gepushed wordt vanuit het hoger managment van onze hoofdaandeelhouder. Waarschijnlijk omdat ze er destijds te veel geld hebben tegen gesmeten voor licenties en programmeurs.

[Janoz]

Wolfboy schreef op woensdag 23 februari 2005 @ 14:43:
Heb je eigenlijk ook al de voor- en nadelen van een webinterface bekeken?
Voordelen:

• Werkt overal zonder installatie
• Relatief snel en eenvoudig in elkaar te zetten
• Centrale instalatie waardoor uitrol van een nieuwe versie simpel is

Nadelen:

• Voor het invoeren van gegevens wordt het automatiseren lastiger (realtime input validatie) Javascript kan heel goed input validatie doen. Kijk bijvoorbeeld eens naar jakarta-commons validator. Hierbij zit een enorme berg standaard javascript voor validatie.
• Bij grote hoeveelheden data langzaam

Er zullen vast wel meer punten te noemen zijn maar deze punten lijken me wel handig om ook te overwegen.

Paar aanpassingen in het voor-/nadelen lijstje. Ikzelf zou gewoon voor een webinterface gaan.

[Morrar]

Ben het met Janoz eens, ook omdat dit een app wordt die door meerdere (fysiek gescheiden) vestigingen gebruikt gaat worden. Daarnaast heb je ervaring in webbased applicaties en dat lijkt me ook een groot pluspunt. Denk overigens nog wel even aan beveiliging voor je al je gegevens zo over het net gaat gooien

[whoami]

Janoz schreef op woensdag 23 februari 2005 @ 15:09:
[...]


Paar aanpassingen in het voor-/nadelen lijstje. Ikzelf zou gewoon voor een webinterface gaan.

Mjah, bij moderne rich client app's kan het ook redelijk makkelijk zijn om een nieuwe versie uit te rollen. Je applicatie moet dan wel goed opgezet zijn (kijk oa eens naar het updater block van MS, of andere mogelijkheden).
Feit is wel dat het met web-app's nog makkelijker is, maar daar heb je gewoon een beperkte UI vind ik.

[Verwijderd]

Er bestaat al een VPN netwerk tussen de verschillende vestigingen dus kan ik het eenvoudig webbased gebeuren gescheiden houden van het Internet. Alhoewel in de vere toekomst waarschijnlijk zaken op het internet zullen komen (die dan wat minder kritisch zijn). Zoals bvb een klant die zijn gegevens kan raadplegen (aankopen, verkopen, ...) Maar deze toekomst muziek kan en mag niet bepalend zijn voor webbased of niet.

[Gerco]

Progress zou ik eerlijk gezegd niet gebruiken voor een webapp, al was het maar vanwege het kosten aspect. Je moet betalen voor het aantal concurrent users op je database en het aantal webspeed processen wat je hebt lopen.

Je kunt een Progress database trouwens prima aanspreken met PHP en ASP, via ODBC en de meegeleverde Merant ODBC driver als je dat toch wilt gebruiken. Voordeel van de ODBC aanpak is dat je webspeed niet hoeft te gebruiken en je dus die kosten niet hebt. Voordeel is ook dat je er zo een andere database onder kunt hangen als het management verstandig is geworden

Dit komt wel van een ex-Progress programmeur btw, ik ben naar .NET/MSSQL/Oracle gevlucht

[ Voor 22% gewijzigd door Gerco op 23-02-2005 15:31 ]

[Verwijderd]

whoami schreef op woensdag 23 februari 2005 @ 15:23:
[...]
Feit is wel dat het met web-app's nog makkelijker is, maar daar heb je gewoon een beperkte UI vind ik.

De mensen waren heel tevreden over de voorganger van de huidige situatie die CUI was, dus ik denk dat ze wel niet zo zitten te popelen op een grafisch hoogstandje. Alhoewel je webbased ook mooie zaken kan maken. In ieder geval moet ik dan héél goed de navigatie uitdokteren om de mensen geen muisarm te bezorgen! (sneltoetsen en goeie tabinstellingen zou dan wel degelijk de boodschap zijn)

[Verwijderd]

Gerco schreef op woensdag 23 februari 2005 @ 15:27:
Dit komt wel van een ex-Progress programmeur btw, ik ben naar .NET/MSSQL/Oracle gevlucht

Ok, mijn argwaan voor Progress is dus niet onterecht.
Ik heb wel gelezen dat het aan de DBA kant een enorm goeie database is en dat het weinig onderhoud vraagt. Volgens mij is Progress te uitgebreid en beschikt het over te weinig support ofwel dure support om dit de lucht in te krijgen en te houden.

edit:
Wel handig om te weten dat ASP en PHP ook overweg kunnen met Progress database. Dan kan ik misschien zo wel een stuk van hun investering terugwinnen en hebben ze het voordeel aan de DBA kant aan hun kunt.

[ Voor 19% gewijzigd door Verwijderd op 23-02-2005 15:36 ]

[whoami]

Verwijderd schreef op woensdag 23 februari 2005 @ 15:29:
[...]


De mensen waren heel tevreden over de voorganger van de huidige situatie die CUI was, dus ik denk dat ze wel niet zo zitten te popelen op een grafisch hoogstandje.

Een CUI is nog sneller om data in te putten...
het gaat hier niet om 'grafische hoogstandjes', maar om de makkelijke en snelle manier van werken.

[Gerco]

Verwijderd schreef op woensdag 23 februari 2005 @ 15:35:
Ok, mijn argwaan voor Progress is dus niet onterecht.

Niet geheel nee, er is nog wel genoeg markt voor Progress hoor, maar het wordt langzaam minder. Andere programmeertalen hebben de 4GL hier en daar al bijna bijgebeend in databaseinteractie en voorbijgestreeft op andere fronten. Progress is bezig zichzelf uit de markt te prijzen, ik denk vooral door de enorme kosten die de klanten van software bedrijven moeten maken om de software te kunnen draaien.

1 van onze klanten was tweemaal zoveel kwijt aan Progress als aan onze software (zo'n €300k bij elkaar). Dat is dan wel voor een (state-reset ) appserver omgeving met enkele honderden gebruikers (per gebruiker een paar honderd euro), maar ook op kleinere schaal gaat dat flink in de papieren lopen en daar heb je als .NET/MSSQL developer gewoon minder last van.

Ik heb wel gelezen dat het aan de DBA kant een enorm goeie database is en dat het weinig onderhoud vraagt.

Dat klopt wel ja. Er valt nier zoveel aan te DBA'en, als het draait, draait het goed en het is zo goed als onverwoestbaar in de nieuwere versies. Progress 8 en lager daarentegen (db >2GB = corrupt, transactie > 1GB rollback, vergeet het maar)

[ Voor 9% gewijzigd door Gerco op 23-02-2005 15:45 ]

[Daventry]

Verwijderd schreef op woensdag 23 februari 2005 @ 14:12:
En kan Progress met andere databases werken dan de Progress Database en kan
een Progress Database gebruikt worden voor bvb met PHP/VB/ASP te benaderen?

Progress kan perfect met andere databases samenwerken ja

Volgens mij met zowat alle databases via ODBC

[Wolfboy]

Janoz schreef op woensdag 23 februari 2005 @ 15:09:
[...]
Paar aanpassingen in het voor-/nadelen lijstje. Ikzelf zou gewoon voor een webinterface gaan.

Met javascript zit je alleen al snel (alhoewel volledig afhankelijk van de developer) aan bepaalde browsers en hun mogelijkheden vast, als er op sommige computers bijvoorbeeld NT4 draait met bijbehorende (dus outdated) IE dan zit je al snel met een probleem.
Maar ik moet toegeven dat het zelfs dan niet echt een probleem zou zijn, ook al kan de client niet overweg met javascript dan is dat daarna serverside wel weer op te vangen.

[Verwijderd]

Mijn ideetje:

.NET is erg goed bezig zich te ontwikkelen, gemakkelijk te beveiligen. Gebruik je een client, kan je die ook (via mono) op linux draaien. Web gaat wel via IIS. ASP.NET 2.0 bevat aanzienlijke verbeteringen op het gebied van postbacks enzo. Ik ben echt een .NET freak, maarja, dat ben ik. Yukon (SQL Server 2005) is ook erg goed...

Nadeel is wel de hoge kosten idd, maar support is gemakkelijk te vinden (ook als developer).

[ Voor 9% gewijzigd door Verwijderd op 23-02-2005 16:00 ]

[Verwijderd]

Wolfboy schreef op woensdag 23 februari 2005 @ 15:55:
[...]
Met javascript zit je alleen al snel (alhoewel volledig afhankelijk van de developer) aan bepaalde browsers en hun mogelijkheden vast, als er op sommige computers bijvoorbeeld NT4 draait met bijbehorende (dus outdated) IE dan zit je al snel met een probleem.
Maar ik moet toegeven dat het zelfs dan niet echt een probleem zou zijn, ook al kan de client niet overweg met javascript dan is dat daarna serverside wel weer op te vangen.

Voor webbased programma's kan je wel wat eisen stellen aan de gebruikers zoals bijvoorbeeld IE en JavaScript aanzetten. (voor gewone websites vind ik dat wel iets anders, dan moet je zoveel mogelijk mensen kunnen bereiken.)

[Verwijderd]

Net te binnen gevallen.

Hoe kan je rapporten samenstellen vanuit een webbased applicatie?
Je kan gewoon een site samenstellen als rapport, maar dan kan
dat wschl wel wat problemen geven bij het afdrukken.

Ofwel ... het formpje maken in een DIV-je van 29 x 21 cm ?
Maar dan moet ik al per document een "afdrukweergave" maken,
wat wel een beetje TE is als je bezoeksrapporten (verzameling
van een stuk of 50 documenten) moet afdrukken.

[bigbeng]

Rapportage kun je natuurlijk ook direct naar een bestand genereren en dit ter download aanbieden. Op die manier kun je dat door een app als Excel of Acrobat Reader o.i.d. op de client laten afdrukken.

Voor rapporten van enkele pagina's kun je met DIV'jes of een print stylesheet nog wel goede zaken doen, maar voor de grotere zou ik toch voor een ander soort oplossing kiezen. Kijk voor html oplossingen ook maar eens rond bij onze buren van W&G

[Wolfboy]

Voor rapporten zou ik eens kijken naar het exporteren naar een PDF bestand, dat is voor de meeste gegevens wel het meest gangbare formaat (ziet er als het goed is overal hetzelfde uit)

[Verwijderd]

Bedenk net dat dat eigenlijk een even groot probleem is bij niet-webbased toepassing.
Alhoewel die meestal al een tooltje ingebakken hebben.

Dus naast de fijne gratis webbrowser als toepassingsomgeving zal er toch nog wel ergens een toepassing op de PC moeten komen om een output van de server te verwerken tot een document.

(Op de server laten verwerken zou voor teveel of toch veel meer dataverkeer zorgen)

* Maar dit wordt eigenlijk allemaal een beetje te concreet om nog maar in de analyse fase te zitten *

[ Voor 12% gewijzigd door Verwijderd op 23-02-2005 18:52 ]

[Verwijderd]

Verwijderd schreef op woensdag 23 februari 2005 @ 18:51:
[..]

Dus naast de fijne gratis webbrowser als toepassingsomgeving zal er toch nog wel ergens een toepassing op de PC moeten komen om een output van de server te verwerken tot een document.

(Op de server laten verwerken zou voor teveel of toch veel meer dataverkeer zorgen)

* Maar dit wordt eigenlijk allemaal een beetje te concreet om nog maar in de analyse fase te zitten *

Ik zou de rapporten juist op de server genereren. De gegevens komen bij een webbased interface namelijk alleen maar voor representatie op de client. PDFje genereren en openen in een apart window van de browser. Of HTML genereren en hopen dat het er in de browser goed uitziet.
Dat laatste werkt vooral goed als je eenvoudige rapporten hebt met veel gegevens en een vaste browser (meestal IE) In dat geval hoef je namelijk niet de complete lijst te genereren en over het internet te pompen maar enkel de pagina die de gebruiker op dat moment wil inzien. Dat geeft dus een veel snelere response dan eerst een PDFje te genereren van 20 pagina's en er achter komen dat de gebruiker eigenlijk alleen geinteresseerd is in de laaste vijf regels.
Wel eist server side processing natuurlijk een zwaardere server dan een client side tool maar als je een webbased concept hebt, ga je niet twee regels verder in je voorstel dat concept om zeep helpen door toch client side tools te installeren.

[Verwijderd]

Die documenten afdrukken wordt dus een verhaal appart maar dus zowiezo mogelijk bij gelijk welke keuze ...

[Dutch_guy]

Ik werk met ASP en heb daar een componentje voor aangeschaft waarmee ik dynamisch PDF's kan genereren, voor bijvoorbeeld rapportages.

Clients hoeven dan alleen de gratis Acrobat reader geinstalleerd te hebben. De verwerking van de PDF gebeurt op de server.

[Verwijderd]

Even mijn "analyse" aangepast.
Ik heb het eens opnieuw uitgewerkt:

Database

> Oracle
Pro : Reeds een licentie (geen extra kost)
Pro : Uitgebreid (triggers, stored procedures)

> Progress
Pro : Reeds een licentie (geen extra kost)
Pro : Voordeel voor DBA, duidelijk en weinig beheer nodig.
Con : Te uitgebreid!
Con : Stijgende kosten door dalende populariteit

> Postgress
Pro : Gratis
Pro : Uitgebreid (triggers, stored procedures)

> MSSQL
Pro : Uitgebreid (triggers, stored procedures)
Con : Licentie nodig

> mySQL
Pro : Gratis
Con : Beperkte functies (triggers,stored procedures)
Con : Niet geschikt voor bedrijfskritische gegevens

Programmeeromgeving

> Oracle Forms :
Pro : Basis ervaring aanwezig
Pro : WYSIWYG toepassingen, snelle ontwikkeling
Con : Kosten voor ontwikkelingsomgeving
Con : Sequentieel programmeren is achterhaald
Con : Eenmaal operationeel, moeilijk aanpasbaar

> Progress :
Pro : Ontwikkelingsomgeving aanwezig
Pro : WYSIWYG toepassingen, snelle ontwikkeling
Con : Geen ervaring aanwezig -> Opleiding (heel duur)
Con : Eenmaal operationeel, moeilijk aanpasbaar
Con : Weinig of dure support

> VB :
Pro : Ervaring aanwezig
Pro : WYSIWYG toepassingen, snelle ontwikkeling
Con : Kosten voor ontwikkelingsomgeving
Con : Eenmaal operationeel, moeilijk aanpasbaar.

> Java :
Pro : Basis ervaring aanwezig
Pro : WYSIWYG toepassingen, snelle ontwikkeling
Pro : Kan zonder kostbare ontwikkelingsomgeving (NetBeans)
Pro : Platform onafhankelijk
Con : Eenmaal operationeel, moeilijk aanpasbaar.

> Webbased :ASP(HTML/XML/CSS/JS) :
Pro : Uitgebreide ervaring aanwezig
Pro : Eenvoudig doorvoeren van wijziginen
Pro : Kan zonder kostbare ontwikkelingsomgeving (Kladblok, HomeSite, ...)
Pro : Platform onafhankelijk
Con : Bij server-side rapport ontwikkeling > veel data verkeer

> Webbased : PHP(HTML/XML/CSS/JS)
Pro : Ervaring aanwezig
Pro : Eenvoudig doorvoeren van wijziginen
Pro : Kan zonder kostbare ontwikkelingsomgeving (Kladblok, HomeSite, ...)
Pro : Platform onafhankelijk
Con : Bij server-side rapport ontwikkeling > veel data verkeer

[P_de_B]

Ik denk dat je de rapportage bij een webbased interface niet te moeilijk moet zien, je hebt nl. veel tooltjes daarvoor. Je kunt een component aanschaffen zoals Dutch_guy zegt, maar er zijn ook uitgebreidere tools als Crystal Reports en ActiveReports die goed webbased rapporten kunnen maken en/of exporteren naar een universeel formaat als PDF.

Daarnaast mis ik nog .Net in je analyse. Ook al voel je je daarin nog niet helemaal thuis je moet het denk ik wel meenemen.

[Verwijderd]

P_de_B schreef op donderdag 24 februari 2005 @ 09:11:
Daarnaast mis ik nog .Net in je analyse. Ook al voel je je daarin nog niet helemaal thuis je moet het denk ik wel meenemen.

Ik reken dat bij VB
Mij maakt dat niet veel uit of het VB 6.0 is of VB.NET
VB.NET ben ik wel nog niet gewoon maar veel verschil zal het niet uitmaken met VB 6.0
Op zich hebben VB 6.0 en VB.NET dezelfde voordelen en nadelen maar als er voor VB kiezen
zal ik wel de .NET aanraden aangezien die nu deftig in de lift zit.

[P_de_B]

Sorry, maar je mag .Net niet vergelijken met VB. .Net is volledig object georienteerd bijvoorbeeld. Daarnaast kun je ook volledige webapplicaties met .Net maken.

VB6 en .Net liggen mijlenver uit elkaar.

[Verwijderd]

Waarom ga je niet gewoon verder met Oracle Forms.

Het bedrijf heeft de licenties ervoor en je hebt de kennis. Als je echt een web-omgeving wil, vanaf versie 4.5 heb je ook Web Forms. Je ontwikkelt gewoon je form C/S, maar je runt hem in een web-omgeving. Web Forms is maar pas echt stabiel en betrouwbaar geworden vanaf versie 6i. (ondertussen is er ook al 9i en 10g) Een nadeel van deze omgeving is zeker het prijskaartje.
Verder in je topic vraag je hoe je rapporten moet maken. Naast Forms heeft Oracle ook Reports, hun reporting tool die heel nauw samenwerkt met Forms. Je kan je rapport in preview mode zien, of meteen naar een printer sturen, of bewaren als ps, PDF of XML file.
Een groot voordeel van deze Oracle tools is de snelheid waarmee je je applicatie kan ontwikkelen. Je gaat hier al snel een factor 2 à 3 keer winnen in ontwikkelingtijd tov een PHP/MySQL omgeving.

Forms kan ook connecteren naar andere database via ODBC. Jaren geleden zat in Oracle Forms een demo applicatie die dit illustreerde naar een access-db. Ik heb het nooit live gezien in een bedrijf .

Kijk ook eens op http://otn.oracle.com voor meer uitleg ivm een mogelijk PHP/Oracle oplossing

[Verwijderd]

Ik heb op school reeds een grote applicatie geschreven in Oracle Forms als project en ik moet eerlijk zijn. Ze mogen dat steken waar de zon niet schijnt! Geen OO mogelijk vind ik het grootste nadeel.

Je kan idd snel formulieren ontwikkelen maar op vlak van navigatie laten ze enorm te wensen over.
Wij hebben weken bezig geweest om een functie te vinden om de sluit knop bovenaan het scherm te laten werken. Het is ons nooit gelukt.

Zelf bij de professioneel ontwikkelde toepassing die we hier nu hebben, werkt deze knop niet en hebben ze overal een stomme knop met een deurtje moeten bij plaatsen.

Bij Oracle Forms zit je trouwens vast aan je ene scherm. Open je voorbeeld het formulier klanten, dan kan je niet nog eens het formulier leveranciers openen.

En ook Reports van Oracle ken ik en ook daar hebben we enorm vele miserie mee gekend. Stel nu dat je een formulier van een klant openstaan hebt en je wil dat afdrukken. Dan moet je bij Reports nog eens zijn naam of zijn klantnummer opgeven. Er bestaat maar een heel slechte communicatie tussen Oracle Forms en Reports.

Uit mijn ervaring zal ik deze ontwikkeling afraden. Het is tenslotte ik die het zal moeten programmeren of aanpassen (indien uitbesteed).

[Wolfboy]

Verwijderd schreef op donderdag 24 februari 2005 @ 09:02:
[knip]
Con : Bij server-side rapport ontwikkeling > veel data verkeer

Daar ben ik het niet zo heel erg mee eens eigenlijk, een gegenereerd PDF bestand neemt niet zo heel erg veel data verkeer in beslag hoor.
Dat lijkt me tenminste geen noemenswaardig punt, html is met alle overhead echt niet veel kleiner dan een pdf oid.
Tenzij je bijvoorbeeld word bestanden gaat gebruiken (die wel gigantisch bloated zijn) zal de hoeveelheid ingenomen bandbreedte niet snel een probleem zijn.

[Janoz]

Om nog even verder te gaan op het raporteren. Het lijkt mij voor de uniformiteit van de raporten erg handig waneer deze centraal gegenereerd worden. Hierdoor heb je geen problemen met outdate logo's, niet aanwezige fonts en andere layout technische afhankelijkheden. Een nieuwe huisstijl kan gewoon op 1 plek worden doorgevoerd.

[Verwijderd]

Een document in PDF is wschl niet zo veel nee ... maar per dag moet daar per vestiging een listing van ongeveer 50 pagina's afgedrukt worden. Ik denk dat een PDF van 50 pagina's wel even het netwerkverkeer kan monopoliseren.

[Verwijderd]

Janoz schreef op donderdag 24 februari 2005 @ 10:01:
Om nog even verder te gaan op het raporteren. Het lijkt mij voor de uniformiteit van de raporten erg handig waneer deze centraal gegenereerd worden. Hierdoor heb je geen problemen met outdate logo's, niet aanwezige fonts en andere layout technische afhankelijkheden. Een nieuwe huisstijl kan gewoon op 1 plek worden doorgevoerd.

Wat ook een feit is natuurlijk ! Had ik even nog niet bij stil gestaan.
Een combinatie van webbased met serverside raportontwikkeling is dus
wel heel eenvoudig aan te passen zonder dat de gebruiker er last van heeft.

Dat is eigenlijk wel een enorm voordeel ten opzichte van niet server based
vooral als je met een gefaseerde overschakeling wil werken. (wet ook enorme voordelen biedt)

[Verwijderd]

Verwijderd schreef op donderdag 24 februari 2005 @ 10:02:
Een document in PDF is wschl niet zo veel nee ... maar per dag moet daar per vestiging een listing van ongeveer 50 pagina's afgedrukt worden. Ik denk dat een PDF van 50 pagina's wel even het netwerkverkeer kan monopoliseren.

1 keer per dag, hoe inefficient ook, is geen probleem (tenzij je een ISDN lijn hebt) Zeker als je het moment van verzenden kan uitzoeken. Daarnaast moet je ook bij een client side tool de complete lijst met gegevens oversturen. Bedenk dan ook nog dat PDF een gecomprimeerd bestandsformaat is. Het is dus heel goed mogelijk (afhankelijk van de data) dat je rapport kleiner is dan alle data die je nodig hebt om dat rapport te genereren bij elkaar.

[ Voor 3% gewijzigd door Verwijderd op 24-02-2005 10:17 ]

[Verwijderd]

Dit is mijn voorgestelde oplossing uit de voorgaande analyse:

Database : Oracle

[1] Er bestaat reeds een licentie voor de Oracle database voor de huidige toepassing waardoor geen extra kost nodig is.
[2] Gegevens zullen eenvoudiger kunnen geexporteerd kunnen worden van de oude toepassing naar de nieuwe database aangezien die op dezelfde database draaien.
[3] De Oracle database is een uitgebreide database met mogelijkheid voor triggers en stored procedures.
[4] De bestaande DBA-ers blijven bij de zelfde database en moeten dus niet aanpassen. Dezelfde servers kunnen blijven gebruikt worden.

Ontwikkelingsomgeving : Webbased ASP(HTML,XML,CSS,JS)

[1] Er is reeds een grote kennis aanwezig voor deze ontwikkelingsomgeving.
[2] Geeft de mogelijkheid om overzichtelijk Object Oriented te programmeren wat in het voordeel is van het onderhoud van de toepassing. Ook hergebruik van code wordt hierdoor eenvoudiger.
[3] Wijzigingen kunnen aan de serverkant eenvoudig doorgevoerd worden zonder aanpassingen te moeten aanbrengen aan de clientkant.
[4] De clients moeten geen software installeren of updaten.
[5] Een betalende ontwikkelingsomgeving is niet nodig maar kan het ontwikkelen vereenvoudigen en dus versnellen.
[6] De toepassing is platform onafhankelijk. Alleen zullen restricties moeten gesteld worden aan het gebruik van de browsers.

Ontwikkeling : Zelf ontwikkelen

[1] Om zoveel mogelijk communicatiefouten te voorkomen en de aanpaswerken achteraf drastisch te verlagen.
[2] Gefaseerde invoering mogelijk en in ontwikkelingsfase reeds kunnen inspelen op kritiek van voorgelegde prototypes en testomgevingen. > Tijdsbesparing !

[whoami]

Verwijderd schreef op donderdag 24 februari 2005 @ 10:59:
Dit is mijn voorgestelde oplossing uit de voorgaande analyse:


Ontwikkelingsomgeving : Webbased ASP(HTML,XML,CSS,JS)

Ikzelf zou niet voor dit kiezen, omdat je dan meestal je presentatie-logica met je data-access en business logica gaat gaan mixen, waardoor je code nogal ononderhoudbaar wordt, maarja... da's mijn mening.

[2] Geeft de mogelijkheid om overzichtelijk Object Oriented te programmeren wat in het voordeel is van het onderhoud van de toepassing. Ook hergebruik van code wordt hierdoor eenvoudiger.

OO in ASP

[Verwijderd]

whoami schreef op donderdag 24 februari 2005 @ 11:02:

OO in ASP

Ja toch ? Je doet me nu twijfelen. Ik heb het allesinds nog niet compleet uitgewerkt, maar volgens mij kan je wel classes maken in VBscript ?

whoami schreef op donderdag 24 februari 2005 @ 11:02:

Ikzelf zou niet voor dit kiezen, omdat je dan meestal je presentatie-logica met je data-access en business logica gaat gaan mixen, waardoor je code nogal ononderhoudbaar wordt, maarja... da's mijn mening.

Je kan toch alles mooi scheiden ? Layout prop je in CSS, weergave in de ASP pagina's, veel voorkomende functies of uitgebreide functies prop je in een file afzonderlijk en include je wanneer nodig. Je kan toch alles mooi scheiden?

[Verwijderd]

Er wordt telkens gesproken over lastige updatebaarheid wanneer er van een rich client gebruikgemaakt wordt. Bij mijn werkgever maken ze gebruik van een rich client die via een citrix omgeving op alle vestigingen te gebruiken is. De applicatie staat echter maar op een plek, wat de beheerbaarheid enorm vergroot.

[whoami]

Verwijderd schreef op donderdag 24 februari 2005 @ 11:07:
[...]


Ja toch ? Je doet me nu twijfelen. Ik heb het allesinds nog niet compleet uitgewerkt, maar volgens mij kan je wel classes maken in VBscript ?

't Is niet omdat je classes kunt maken, dat je daarom OO aan het werken bent....
OO is meer dan 'classes maken'. OO gaat 'm over abstractie, encapsulatie, polymorphisme.

Je kan toch alles mooi scheiden ? Layout prop je in CSS, weergave in de ASP pagina's, veel voorkomende functies of uitgebreide functies prop je in een file afzonderlijk en include je wanneer nodig. Je kan toch alles mooi scheiden?

Zolang je je er maar aan houdt, maar toch hou ik er niet van.

[Verwijderd]

Verwijderd schreef op donderdag 24 februari 2005 @ 11:09:
Er wordt telkens gesproken over lastige updatebaarheid wanneer er van een rich client gebruikgemaakt wordt. Bij mijn werkgever maken ze gebruik van een rich client die via een citrix omgeving op alle vestigingen te gebruiken is. De applicatie staat echter maar op een plek, wat de beheerbaarheid enorm vergroot.

Een rich client die centraal staat ? Heeft dat dan niet veel dataverkeer ?

De vestigingen liggen op meer dan 100 km van elkaar. En zijn via het Internet over een VP met elkaar verbonden en dus niet via een bliksemsnelle LAN verbinding.

[Verwijderd]

Neen, geen objecten in asp! Ben er vrijwel zeker van. Ben eer helemaal zeker van dat ik het nog niet gezien heb, maar dat wil natuurlijk niet zeggen dat het niet bestaat.

OO komt pas vanaf .Net!

[whoami]

Verwijderd schreef op donderdag 24 februari 2005 @ 11:16:
OO komt pas vanaf .Net!

Ehm, dat is nu ook weer zever, want er bestonden al OO talen in de jaren 70 - 80, etc...
Java, C++, Smalltalk, Object Pascal etc... zijn allemaal OO talen en bestonden al lang voordat er sprake was van .NET

[Verwijderd]

whoami schreef op donderdag 24 februari 2005 @ 11:11:
Zolang je je er maar aan houdt, maar toch hou ik er niet van.

Als je een uitgebreide toepassing maakt kan je gewoon niet anders. Of je verliest zelf alle overzicht.
Laat staan dat een externe programmeur of een eventuele opvolger er iets moet van snappen.

whoami schreef op donderdag 24 februari 2005 @ 11:11:
't Is niet omdat je classes kunt maken, dat je daarom OO aan het werken bent....
OO is meer dan 'classes maken'. OO gaat 'm over abstractie, encapsulatie, polymorphisme.

Uhu, 't is niet echt OO zoals java (wonder mooi trouwens) en zoals het hoort om echt OO te zijn.
Maar het heeft toch heel wat voordeel ten opzicht van PHP als je overzichtelijk wil programmeren.

PHP is ook goed, maar moeilijk om overzicht te bewaren. (persoonlijke mening hé)

[Verwijderd]

Verwijderd schreef op donderdag 24 februari 2005 @ 09:34:
Je kan idd snel formulieren ontwikkelen maar op vlak van navigatie laten ze enorm te wensen over.
Wij hebben weken bezig geweest om een functie te vinden om de sluit knop bovenaan het scherm te laten werken. Het is ons nooit gelukt.

het 'exit_form' statement in de when_window_closed' trigger lijkt mij niet zo moeilijk.

Verwijderd schreef op donderdag 24 februari 2005 @ 09:34:
Bij Oracle Forms zit je trouwens vast aan je ene scherm. Open je voorbeeld het formulier klanten, dan kan je niet nog eens het formulier leveranciers openen.

Vast zitten aan 1 scherm, dit lijkt mij heel onlogisch in een MDI omgeving. Je hebt 3 statements die andere forms openen. open_form, call_form, new_form

Verwijderd schreef op donderdag 24 februari 2005 @ 09:34:
En ook Reports van Oracle ken ik en ook daar hebben we enorm vele miserie mee gekend. Stel nu dat je een formulier van een klant openstaan hebt en je wil dat afdrukken. Dan moet je bij Reports nog eens zijn naam of zijn klantnummer opgeven. Er bestaat maar een heel slechte communicatie tussen Oracle Forms en Reports.

Ofwel kent je leraar er niets vanaf, ofwel heb jij veel gespijbelt, maar slechte communicatie is totale onzin.

Verwijderd schreef op donderdag 24 februari 2005 @ 09:34:

Uit mijn ervaring zal ik deze ontwikkeling afraden. Het is tenslotte ik die het zal moeten programmeren of aanpassen (indien uitbesteed).

Forms is inderdaad niet echt een 'fancy' omgeving om in te werken. Het ontbreken van de laatste widgets zoals listviews, panels, dockable toolbars (om er maar enkele te noemen) zijn zeker een nadeel. Het lijkt er op dat je bang bent om voor deze omgeving te kiezen, omdat je er niet veel ervaring in hebt. Maar neem van mijn aan dat Forms en Reports krachtige, robuuste tools zijn die zowel op Windows als op *Nix systemen werken.
En om aan je klant deze omgeving af te raden nadat hij er zoveel geld heeft ingestoken lijkt mij niet zo'n goede zet te zijn naar je klant toe.

Maar je kiest zelf natuurlijk een programmeertaal waar je je zelf goed bij voelt.

PS : vergeet bij de pro/cons niet, als je kiest voor een IIS, het prijskaartje te vermelden, of is die zoals Apache ook gratis.

[Sybr_E-N]

whoami schreef op donderdag 24 februari 2005 @ 11:17:
[...]


Ehm, dat is nu ook weer zever, want er bestonden al OO talen in de jaren 70 - 80, etc...
Java, C++, Smalltalk, Object Pascal etc... zijn allemaal OO talen en bestonden al lang voordat er sprake was van .NET

offtopic:
Volgens mij bedoelt Yellow_Snow OOP in ASP en niet in het algemeen. In ASP.Net is wel OO aanwezig in C# en VB.net enzo.

[Verwijderd]

Verwijderd schreef op donderdag 24 februari 2005 @ 11:28:
het 'exit_form' statement in de when_window_closed' trigger lijkt mij niet zo moeilijk.

Hebben we destijds zeker geprobeerd, dat herinner ik mij nog levendig, zo stond het ook in ons boek, maar het venster weigerde te sluiten.

Vast zitten aan 1 scherm, dit lijkt mij heel onlogisch in een MDI omgeving. Je hebt 3 statements die andere forms openen. open_form, call_form, new_form

Ja, vanuit andere forms kan je opnieuw forms openen, dat weet ik. Maar voorbeeld van uit een menustructuur bovenaan het klantenformulier en het leveranciersformulier naast elkaar openen was toen ook één van de zaken waar we ons hebben op suf gezocht.

Ofwel kent je leraar er niets vanaf, ofwel heb jij veel gespijbelt, maar slechte communicatie is totale onzin.

Ik heb in mijn hele schooltijd geen één dag gespijbeld. Maar het is een feit dat onze docenten er geen kloten van kenden. We konden met NIETS bij hen terecht.

Forms is inderdaad niet echt een 'fancy' omgeving om in te werken. Het ontbreken van de laatste widgets zoals listviews, panels, dockable toolbars (om er maar enkele te noemen) zijn zeker een nadeel. Het lijkt er op dat je bang bent om voor deze omgeving te kiezen, omdat je er niet veel ervaring in hebt. Maar neem van mijn aan dat Forms en Reports krachtige, robuuste tools zijn die zowel op Windows als op *Nix systemen werken.
En om aan je klant deze omgeving af te raden nadat hij er zoveel geld heeft ingestoken lijkt mij niet zo'n goede zet te zijn naar je klant toe.

Het is niet voor een klant die ik werk. Ik ben nieuwe IT-er in het bedrijf zelf en helemaal niet te spreken over de huidige toepassing.

Ik weet niet of het standaard procedure is om de ontwikkelingsomgeving ook aan te schaffen als je de ontwikkelde forms wil kunnen uitvoeren. Maar die hebben ze dus wel degelijk alhoewel ze die nooit gebruikt werden want het programma werd door een extern bedrijf geschreven.

Maar je kiest zelf natuurlijk een programmeertaal waar je je zelf goed bij voelt.

PS : vergeet bij de pro/cons niet, als je kiest voor een IIS, het prijskaartje te vermelden, of is die zoals Apache ook gratis.[/quote]

[Wolfboy]

Over de discussie of het nou wel of niet OO is, ik denk/verwacht dat de TS het over ASP.Net heeft en niet over ASP 3.0, met ASP.Net is er wel OO aanwezig en dat is dus ook geen probleem.
Aangezien de servers nog geplaatst moeten worden lijkt het me geen probleem om direct met ASP.Net te beginnen, je zit namelijk niet vast aan de huidige omgeving.

[Verwijderd]

Wolfboy schreef op donderdag 24 februari 2005 @ 11:56:
Over de discussie of het nou wel of niet OO is, ik denk/verwacht dat de TS het over ASP.Net heeft en niet over ASP 3.0, met ASP.Net is er wel OO aanwezig en dat is dus ook geen probleem.
Aangezien de servers nog geplaatst moeten worden lijkt het me geen probleem om direct met ASP.Net te beginnen, je zit namelijk niet vast aan de huidige omgeving.

Nee, nu staat er al per vestiging reeds een Oracle Database te draaien voor de huidige toepassing.

Hoe ik de database ga organiseren weet ik ook nog niet precies. De database op 1 server plaatsen en de overige twee als backup gebruiken. Wat wel voor grotere wachttijden zal zorgen voor de vestigingen het verst van de server. Andere methodes ben ik nog niet aan uit. Onze DBA docent was ook niet zo'n straffe kadé. En heeft ons veel te veel bezig gehouden met details en pruts ipv ons een ruim theoretisch overzicht te geven... naja. In onze cursus hebben we bvb alleen maar een Oracle Database opgezet ! WAW ! Toen wisten we echt wel wat DBA-en was (NOT!)

[whoami]

Verwijderd schreef op donderdag 24 februari 2005 @ 12:05:
[...]
Hoe ik de database ga organiseren weet ik ook nog niet precies. De database op 1 server plaatsen en de overige twee als backup gebruiken. Wat wel voor grotere wachttijden zal zorgen voor de vestigingen het verst van de server. Andere methodes ben ik nog niet aan uit. Onze DBA docent was ook niet zo'n straffe kadé. En heeft ons veel te veel bezig gehouden met details en pruts ipv ons een ruim theoretisch overzicht te geven... naja. In onze cursus hebben we bvb alleen maar een Oracle Database opgezet ! WAW ! Toen wisten we echt wel wat DBA-en was (NOT!)

Je kan er ook voor kiezen om op iedere site een server te zetten, en de mensen van site X gebruiken de server die op Site X staat.
Je laat de 3 servers dan in een merge - replication draaien, en zo werkt iedereen op de dichstbijzijnde server als deze beschikbaar is, en worden toch alle 3 de servers gesynchroniseerd.

[Verwijderd]

whoami schreef op donderdag 24 februari 2005 @ 12:08:
[...]


Je kan er ook voor kiezen om op iedere site een server te zetten, en de mensen van site X gebruiken de server die op Site X staat.
Je laat de 3 servers dan in een merge - replication draaien, en zo werkt iedereen op de dichstbijzijnde server als deze beschikbaar is, en worden toch alle 3 de servers gesynchroniseerd.

Die synchronisatie moet dan toch wel hoog liggen. Als bvb facturen gemaakt worden.

13:16 > Vestiging X > Factuur volgnummer : 12334
13:17 > Vestiging Y > Factuur volgnummer : 12335 !
Als na 13:16 en voor 13:17 niet gesynchroniseerd is, zit je misschien wel met een foute factuur.

Ik had ook aan synchronisatie gedacht, maar ik zie niet direct hoe zo iets kan werken en de database correct blijft.

[whoami]

Dat kan je oplossen door ieder factuurnr bv te laten beginnen met het nr van de vestiging....

[Verwijderd]

whoami schreef op donderdag 24 februari 2005 @ 12:18:
Dat kan je oplossen door ieder factuurnr bv te laten beginnen met het nr van de vestiging....

Facturen moeten toch logisch in de tijd genummerd worden?

Dus kan dit toch niet ?
Factuur op maandag uit vestiging 3 > 31255
Factuur op dinsdag uit vestiging 1 > 13652

Naja, hier gaat het al weer enorm in detail, maar blijkbaar hebben kleine details ook weerslag op de algemene hardware structuur van de servers.

[Verwijderd]

Welke functionaliteiten gaat je applicatie allemaal bevatten. Je zeg dat je een oude apps gaat herschrijven met 280*30% = 90tal tabellen. Dit lijkt me niet echt een kleine apps.
Ga je deze appplicatie alleen maken of werk je er met een team aan. 90 tabellen is toch wel een aantal maanden werk.

[Verwijderd]

Verwijderd schreef op donderdag 24 februari 2005 @ 12:28:
Welke functionaliteiten gaat je applicatie allemaal bevatten. Je zeg dat je een oude apps gaat herschrijven met 280*30% = 90tal tabellen. Dit lijkt me niet echt een kleine apps.
Ga je deze appplicatie alleen maken of werk je er met een team aan. 90 tabellen is toch wel een aantal maanden werk.

Nee. De huidige applicatie heeft 280 tabellen waarvan er misschien maar 60 gebruikt worden. Die 30 % was dan blijkbaar nog ruim genomen :-S

Ik heb nu al een tijdelijk database model klaar adhv van gespreken met de gebruikers en manageres. Want dat model is toch onfhankelijk van de keuze van de database ... Daarin heb ik al ongeveer 25 tabellen, maar daar moet nog wat systeemtabellen tabellen bijkomen zoals een tabel met gebruikers, een tabel met configuratiegegevens en rollen om toe te kennen aan gebruikers, tabellen met alle begrippen in verschillende talen (want de appi moet ook in Wallonië gebruikt worden), ...

Het zal de bedoeling zijn dat ik het alleen ontwikkel, maar dan heb ik wel 8 uur per dag tijd om er aan te werken. En tot ongeveer halverwege augustus.

[ Voor 8% gewijzigd door Verwijderd op 24-02-2005 13:37 ]

[Verwijderd]

Wat Pro en Cons later zijn we tot de volgende gekozen oplossing gekomen.

Database : Progress
Enigeste database met DBA-kennis. Ik had zelf wel DBA kennis van Oracle, mySQL, MSSQL maar ik heb geen zin om bij de server in Nederland te gaan wonen (Ik ben Belg)

Programmeer omgeving : Progress EN Webbased
De Progress ontwikkeling wordt uitbesteed en aangepast in Nederland terwijl ik een webbased applicatie ontwikkel. ...Dat de beste dus mag winnen... :-)