Alef Arendsen

Kijk dat zijn de antwoorden!! En dan nog marketingtips op de koop toe... Helemaal top!

Ik heb een extra handelsnaam geregistreerd voor onze beevee, nu wilde ik even checken hoe de administratie dan in z'n werk gaat... Ik kan - neem ik aan - facturen sturen uit naam van deze handelsnaam. Deze kunnen neem ik aan gewoon meegenomen worden in m'n huidige administratie (wat betreft nummering, boekhouding, BTW-nummers)??

Nee, is sinds een aantal jaren niet meer mogelijk. Een bepaald percentage van het oppervlak van de kleding moet bedekt zijn met logo's of ander promotiestuff...

Een kernreactor op Mars? Waarom niet gewoon op de maan, of willen ze zo'n mega-grote reactor bouwen dat als ie ontploft ie de aarde ook wegvaagt?

Ik denk dat je het in dit geval over een aansprakelijkheidsverzekering hebt. Dit is zeker verstandig om te doen en kost heel erg weinig... Een rechtsbijstandverzekering helpt je ingeval van processen, rechtzaken, etcetera...

Als ze lid zou zijn, kreeg ze een reusje... Ik wil best betalen, maar niet op deze manier :)

By the way, in Amerika is er al zo'n initiatief, de NBTA (Nick Bolletieri Tennis Academy - zie ook http://www.imgacademies.com/tennis/default.jsp). Daarnaast, ik weet het niet zeker, maar is deze school niet gelieerd aan het Key Biscane tournooi (toch de vijfde grandslam zeggen ze). NBTA zit in Florida, en als ik me niet vergis vlak onder Miama, waar ook Key Biscane zit... o ja, die NBTA doet het overigens altijd erg goed, quote van de website: The NBTA (Nick Bollettieri Tennis Academy) system of instruction has produced many of the world's top players, including Jim Courier, Andre Agassi, Monica Seles, Tommy Haas and Anna Kournikova

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! 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. 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. 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...

Mijn ervaringen: Bedrijfsvorm belangrijk: ja! Een B.V. geeft voordelen. Omdat deze op de langer termijn ook via de belastingdienst een minimum inkomen vraagt... De laatste keer dat ik zelf geinformeerd heb voor een hypotheek hoefde ik niets over te leggen, geen cijfers niks... Ze wilden wel en contract zien, maar toen ik zei dat ik dat zelf had opgesteld en dat dus eigenlijk onzinnig was gaven ze me gelijk en kon ik zo de hypotheek krijgen (als ik gewild had). Eerlijkgezegd denk ik dat dat tegenwoordig wel ietsje anders ligt... Ik hoor slechte verhalen van mensen die hypotheken aanvragen...

Hmmm, kweenie... De belastingdienst zegt: Dit betekent dat jou methode zou mogen... Maar: als ik inspecteur zou zijn zou ik zeggen: heeee, jij hebt de mogelijkheid facturen tussen te voegen... Maar ik denk dat dat wel los zal lopen hoor...

Ja kom op, jij zou toch zeker ook een vriend of goede zakenrelatie als referentie opgeven? Je betaalt al niet op tijd, dus je toekomstige klant oplichten met lovende referenties doe je vast ook ;D p.s. sorry hoor annedien, ik ben een beetje in een uitgelaten lach-stemming vandaag omdat ik morgen mijn laatste dagje heb voor m'n eerste vakantie sinds een jaar...

Ha Annedien, goed dat je deze thread met je reactie even activeert, want ik kwam laatst het aangehangen documentje tegen over Goal-Directed Design (GDD) wat blijkbaar door veel interaction designers gebruikt wordt en RUP (Rational Unified Process), een beproefde methode voor software ontwikkeling (hoewel ik van RUP niet zo gecharmeerd ben, gezien de mate waarin het rigide is). Als ik zoek op Google op goal-directed design krijg ik nog wel wat andere interessante links terug, misschien leuk... Een van die links: http://www.campagne.com/gdd_print.html RUP__Goal-Directed_Design.doc

Wij maken vrij veel gebruik van provisie en hanteren dit principe altijd. Tis zelf zo dat de een eventuele factuur voor provisie alleen verstuurd mag worden indien betaling van de klant binnen is... Geeft helaas degene aan wie je provisie geeft wel wat inzicht in jou debiteurenbeheer, maar goed, dat vind ik persoonlijk niet zo erg...

Kunnen we dit niet gereguleerd laten updaten door bepaalde mensen (admins ofzo). Je kunt bij hun een request indienen, de admin gaat er dan achteraan... Klinkt wel als een leuke service (en zeker naarmate we bij grotere bedrijven moeten aankloppen een behoorlijke publiekstrekker)...

Ha Ben, je was me voor ;) 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!

Leuke discussie!!! Typisch voorbeeld van een database-georiënteerde (Rémy) bouwer versus een applicatieplatform (dit geval J2EE) georiënteerde bouwer. 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... 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. 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... 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! 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... 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...

Wat mij wel een optie lijkt is het betreffende bedrijf gewoon melden dat er negatieve publiciteit rond zijn/haar persoon is en of deze persoon hierop wil reageren... Deze communicatie ook gewoon hier posten en dat in draadje afwikkelen. Op die manier geven we iedereen eerlijk de kans zich te rechtvaardigen... Ik ben wel een beetje huiverig voor flame-wars trouwens als we dit echt gaan doen... Aan de andere kant wel weer grappig als we Scheepbouwer hier over een maandje tegenkomen omdat er geklaagd is over KPN ;D

Ja, helemaal waar! De theorie is ook wel degelijk verschillend, al is het niet veel... Een paar voorbeelden... Wist u dat: Rijden zonder handschoenen niet veilig is Rijden zonder helm niet mag Inrijden in een weg verboden voor voertuigen met meer dan twee wielen met een motor dus wel mag (rond bord, rode rand, auto erin). Veel mensen weten dit niet eens... Achterop zitten tot en met een bepaalde leeftijd niet mag Tussen de file doorrijden mag, zolang je je aan bepaalde regels houdt... De manier waar je een bocht aansnijdt volgens de theorie veilig of niet veilig is... Vragen die je tijdens auto-theorie niet krijgt, bij motortheorie wel... En buiten dat: je auto theorie is maar één jaar geldig, dus is sowieso inmiddels wel verlopen... Overigens is het niet moeilijk hoor, doe een paar keer een oefentheorie-examen op www.driversonly.nl bijvoorbeeld en je bent erdoor...

Twas dus eigenlijk net zo simpel als ik al dacht... Thanx!!!

Tsja, tis zeker niet goedkoop, ik betaalde 35 euro en dat is nog niet eens erg prijzig voor Amsterdam wat ik hoorde... Ik was in totaal bijna 1000 euro kwijt voor het hele zwikkie (inclusief theorie en praktijkbla). Kijk even of je een KNMV gecertificeerde instructeur kunt vinden, die hebben een soort extra keurmerk en das wel zo goed... kijk even op: http://www.knmv.nl/asp/menu_drop.asp?id=350&subid=360 daar staan de instructeur bij jou in de buurt...

O jee, jij en een Ducati? Hmmm, hier moet ik effe over nadenken ;D

Ik moet even een credit nota versturen (tjsa, dat moet soms - helaas - ook gebeuren). Het gaat in dit geval om een korting van 10% die achteraf op een door de debiteur nog niet betaalde factuur gegeven wordt. Ik neem aan dat ik kan volstaan met het kortingsbedrag en een opmerking dat deze creditnota verrekend kan worden met factuur nummer XXX??? Moet ik nog ergens het eindbedrag vermelden wat er dan overblijft (of kan dit in een begeleidend schrijven)? thnx, Alef

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: 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. 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).

Op een of ander forum voor motorrijders waar ik ook wel eens kom, zouden de volgende 10 berichten gevuld zijn met het smiley wat we hier ook wel toe zouden kunnen voegen: Wat betreft die vrachtwagens, ik doe hetzelfde, als ik die gasten er niet tussenlaat, ben ik echt niet sneller op me werk... En Kermie: die onvoorspelbare motorrijders, dat zijn vast de Ducati Monsters of de R1's onder ons, daar associeer ik me ook niet graag mee... ;) Toch heb je wel humor :)

Rebel Kermie in actie... Explain ;D p.s. ben het overigens wel met je eens hoor