Rémy

Bedankt voor je antwoord! Duidelijk en logisch! Stuur ik die gegevens meteen op naar hem, kunnen wij eindelijk ons geld krijgen :D

Beetje vage onderwerptitel, maar mijn vraag is als volgt: Ik heb een vof met twee andere venoten en wij hebben twee maanden gewerkt voor een bedrijf in onderaanneming (bouwsector) en hebben hiervoor uren gefactureerd. De eerste maand zat er nog een bedrijf x tussen (dus wij waren in onderaanneming bij bedrijf x, die weer in onderaanneming was bij de hoofdaannemer). Aangezien hij tevreden was met ons en bedrijf x er tussen uit wou, zijn wij voor de tweede maand direct voor hem gaan werken. De eerste maand is keurig betaald aan bedrijf x en bedrijf x heeft ons betaald. Wij moesten toen wel VAR-verklaring overlegen, om te bewijzen dat er geen sociale lasten afgedragen hoeven te worden. Dat vond ik al raar, want wij zijn toch een vof met een BTW-nummer, maar heb dit gewoon aangevraagd. Nu bij het versturen van de factuur van de tweede maand, belt de hoofdleverancier dat het een en ander niet klopt. Hij wist niet dat wij een vof waren en kende ons hele bedrijf niet. Hij dacht dat wij zzp'ers waren (bedrijf x had dat gezegd) en nu heeft hij een aantal dingen nodig, om zich zelf in te dekken voor de belastingdienst. Hij wil van ons een kvk-uitreksel, de manuren gespecificeerd hebben per persoon (met naam erbij) een een verklaring van de belasting dat hij geen sociale lasten hoeft te betalen (hij was niet duidelijk wat voor verklaring hij dan bedoelde). Ik zie even niet in waarom nu alles anders is omdat het een vof blijkt te zijn. Een zzp'er is toch gewoon een eenmansbedrijf, dus wat voor verschil zou daar inzitten t.o.v. een vof? En waarom wil hij nu een uitreksel hebben van kvk (wat ik hem op zich zou kan geven, das geen probleem)? En dan de uren... Wat voor nut heeft het om de uren per persoon te specificieren, als wij 'als bedrijf' arbeid hebben geleverd? We hebben hebben daarvoor ook een week een zzp'er ingehuurd, om het werk gedaan te krijgen (een project van de hoofdaannemer). Opzich kan ik de uren per persoon specifieren en heb ik de var-verklaring en kvk-uitreksel van de zzp'er die wij ingehuurd hebben, dus het zou geen probleem moeten zijn als dit moet (maar ik zie dus niet waarom?). Nu allen het derde punt: de verklaring... Wat voor verklaring bedoelt hij? De hoofdaannemer zegt dat je dat gewoon kan opvragen, als je zegt dat de hoofdaannemer dit wil hebben. Echter de belastingdienst is telefonisch onbereikbaar (AL WEKEN :(). Is het feit dat je een kvk-nr hebt, een BTW-nummer en VAR-verklaringen niet meer dan genoeg? Hopelijk weten jullie hier meer vanaf...

Het zijn inderdaad de eerste facturen (en de eerste keer in onderaanneming). Door omstandigheden (haast\hoeveelheid gegarandeerd werk\goede vriend die de hoofdaannemer is) zijn de afspraken maar globaal overeengekomen en niet op papier gezet (ik weet het = stom). Ik denk dus dat ik met die pauzetijd toe te moeten geven (kan hier op zich ook nog wel in mee gaan en heb hier ook wel begrip voor), dus probeer inderdaad dit rechtsom enigzins te comperseren. Dus jullie vinden het logische dat ik 2x de reistijd door belast (vind ik namelijk óók :))? Dit scheelt mij 37,5% van de uren die de hoofdaannemer in mindering wil brengen en daar kan hij, mijn inziens, geen goede argumenten tegenin brengen (net zoals ik niet tegen zijn pauzetijd-vermindering).

Goedenavond, Ik heb twee mensen (mede-eigenaren van de vof) uitgeleend (onderaanneming) aan een ander bedrijf. Hiervoor heb ik facturen verstuurt voor de gemaakte arbeidsuren, reistijd en kilometervergoeding. De hoofdaanemer gaat niet akoord met deze facturen, omdat hij vindt dat hij niet de pauses hoeft te betalen en wil dus voor elke dag één uur afhalen per persoon (dus 2uur per dag). ik ben het hier niet helemaal met hem eens, aangezien ik vind dit bij het werk hoort. Wat vinden jullie hiervan? Mag ik deze tijd gewoon als arbeidsuren doorbelasten? Als ik dan toch deze pauze-uren van de factuur afhaal, wil ik de reistijd anders berekenen. De twee uitgeleende personeelsleden rijden samen in één bus, naar de locatie (bouw), in 45min in 59km. Ik belast nu 1x45min en 59km door, maar wil dit veranderen in 2x45min en59km. Dit omdat er twee personen die reistijd maken. De kilometervergoeding blijft hetzelfde, want dat betreft de gereden km per bus. Vinden jullie dat ik zou mag rekenen (dus 2x reistijd)? Mvg, Rémy p.s. Ik heb dit helaas niet vooraf afgesproken met de hoofdaannemer :'(.

Ik zie echt niet wat er nieuw is. Er zijn hiervoor toch al universele technieken: 1. CSS; Hiermee kan de ontwerper al een heleboel doen. Zie http://www.csszengarden.com/ voor de mogelijkheden. 2. XML\XLS; Mocht CSS niet voldoende zijn dan is er XML\XLS waarmee een ontwerpen zelfs kan bepalen welke data op wat voor manier weergegeven kan worden. Zie http://www.altova.com/ voor goede tools. -Rémy

Heb lange avonden moeten doorhalen, dus kon helaas niet eerder reageren, maar het is inderdaad een leuke discussie. Of ik een database-georiënteerde bouwer ben? Zou kunnen :) Ik ben begonnen als programmeur (en doe dit nog steeds), maar mijn denken over applicaties is toch veranderd. De database is voor mij de basis van elke applicatie, de onderste laag van een n-tier framework, dus benader ik zaken vanuit de database. Mmmm...lijkt er wel op dat ik een database-georiënteerde bouwer ben ;) En dat is het hem nou juist. Een DBA'er mag niemand vertrouwen, dit is zijn werk ;). De DBA'er dient o.a. voor de integeriteit van de data te zorgen en dit kan\mag je niet in de handen van de programmeur leggen, ook al zit deze aan de andere kant van het buro en drinkt hij af en toe een biertje met hem :). En zelfs als de programmeur dezelfde persoon is als de DBA'er, dan dient hij dit strict te scheiden. Een fout in de applicatie, mag geen invloed hebben op de integeriteit van de data. Nu klink ik wel heel erg als een database-georiënteerde bouwer ;). Ik begrijp nu waarom door je uitleg over je persistence-framework dat je gebruikt (bedankt voor de link) en dit is op zich een hele andere benadering. Zelf zou ik hier nooit voor kiezen. Ik vind dat de RDBMS voor de dataintegeriteit dient te zorgen, niet een laag er boven. Je hebt gelijk dat je in J2EE dingen kunt hergebruiken (je businesslogic) voor verschillende applicaties, webservices, etc. Echter je bent nu wel gebonden aan java en dat is een keuze die ik persoonlijk niet zou maken. Als ik jouw reactie van punt 3,4 en 5 samenvat begrijp ik jouw insteek, maar dan geef je het applicatieplatform de verantwoordelijk over de data(-integeriteit) en gebruik je database meer als een opslagmedium om je data op te slaan. Hier kun je voor kiezen, maar zelf vind ik dat de verantwoordelijk van de data bij de database hoort te liggen. Als de applicatieplatform weggevalt en je zou de database op een andere manier (bv .NET of direct via SQL) benaderen dan zou de database, in jouw geval, de dataintegeriteit niet kunnen behouden, want die zit in je applicatieplatform. En speciefiek punt 4: Ik geef je helemaal gelijk dat je de database niet wil hitten voor datavalidatie. Ik zou dit bij de hoogste layer van een n-tier platform willen checken om onnodig beslag op de servers te vermijden. Maar dat wil niet zeggen dat de onderliggende layers de invoer niet hoeft te controleren (stel dat de laag er boven niet goed geprogrammeerd is). Ik vind dat de RDBMS alsnog de taak heeft om de data te controleren die ingevoerd wordt, want hij mag niet blind er vanuit gaan dat dit altijd correct is. Heb je gelijk in: MySQL ontwikkeld zich de goede kant, maar dingen zoals foreign key's, sub-selects, etc. werken alleen nog met bv. de InnoDB-type of in 4.1 (die nog een alpha-status heeft). En bij gebruik van de InnoDB-type, valt het voordeel van MySQL weg: snelheid. Andere databases, zoals PostgreSQL, zijn dan sneller... En hosting met InnoDB zijn er niet zoveel van.... Ik hoop juist dat ze MySQL goed doorontwikkelen, maar op dit moment hebben ze nog een flinke weg te gaan. Lees wel dat ze proberen storedprocedures, triggers en views in versie 5 te krijgen, dus dat ziet er hoopvol uit, maar eerst noemde ze dit soort dingen onnodig en onzinnig.... Als vervanging voor Oracle of SQLserver (als je deze producten tenminste volledig gebruikt) is het gewoon nog geen optie. Je hebt gelijk: het komt inderdaad een beetje aanvallend over terwijl dit helemaal niet mijn bedoeling is. Tja, de topicstarter heeft niet meer van zich laten horen (ben toch nog benieuwd of hij gaat overstappen) en de discussie is inderdaad een andere kant opgegaan, maar om het een goeie titel te geven: Enerzijds gaat het over de 'enterprise-'databases vs. de kleinere databases en of deze elkaar kunnen vervangen, anderzijds over welke taken een database dient te verichten en welke taken de applicatie (wat op zich ook weer meespeelt bij de keuze voor een enterprise\kleine database). Een goede titel is dan denk ik: "Welke andere database kan mijn huidige (enterprise-)database vervangen?" (Blijft dan toch bij de vraag van de topicstarter, maar maakt het wat algemener ;)) -Rémy

Het feit dat jij een RDBMS alleen daarvoor gebruikt, betekend dat jij aan een database, zoals MySQL genoeg hebt. (En volgens mij zie je nog niet in wat stored procedures/triggers/views voor je kunnen betekenen. Als je er eenmaal mee werkt wil je niet meer terug ;)) De gegevens(data) van een bedrijf is het meest belangrijkste wat er is, niet de applicaties, die kunnen opnieuw gebouwd worden. Deze gegevens dienen door een goede RDBMS beheert te worden, zodat kans op vervuiling of verlies van gegevens zo klein mogelijk wordt. Een RDBMS is een 'applicatie' die je data beheert, in de ruimste zin van het woord. Standaard SQl? Elke database heeft een eigen SQL-dialect (heet T-SQL bij SQLserver) en óók al probeer je zo standaard mogelijk te werken het blijft een utopie een SQL-commando te hebben die in alle databases hetzelfde is. Simpele SQL-commando's zou misschien nog lukken, maar zodra het iets ingewikkelder wordt dan houdt het al op. Een abstractielaag in je applicatie wordt dan nutteloos, want je dient je SQL te herschrijven. Maar waarom zou je niet alle handige speciefieke functies van de betreffende database gebruiken? Het vergemakkelijkt je ontwikkeling en in de praktijk wordt er zelden van database verandert. De kans is veel groter dat er van applicatie verandert wordt... of men wil de data op meerdere manieren benaderen (webpagina, webservice, etc.). Hoe los je dit op? Al je businesslogic zit in je applicatie, zoals je zelf al zegt.... Waarom niet? Wil je dan al je businesslogic in elke applicatie, die gebruikt maakt van je data, implementeren.... Waarom niet de RDBMS een gedeelte van je businesslogic laten afhandelen en hier een abstractielaag in creëren, waardoor je applicatie hele simpele SQL-commando's naar de database kan sturen (zelfs zonder joins!)? Waarom zou je de applicatie de controle op de data uitvoeren, terwijl dit een taak is van de RDBMS. En hier zijn stored procedures, triggers en views uitermate belangrijk voor! Laat ik het simpel uitleggen wat een goede RDBMS dient te doen: 1.Stel ik heb een 'flat database' en ik wil één kolom met unieke waarden hebben (bv. klantnr). Dan dien ik dit te controleren, door alle waardes te doorlopen. Dit zou ik in mijn applicatie moeten doen? Is het niet handiger om dit de RDBMS te laten doen? Natuurlijk! Daarom ondersteunen zelfs de simpelste databases dit. 2.Ik wil een uniek klantnr hebben dat oploopt. Moet ik alle klannr doorlopen en dan de hoogste klannr met 1 ophogen. Dit zou ik in mijn applicatie moeten doen? Is het niet handiger om dit de RDBMS te laten doen? Natuurlijk! Gelukkig ondersteunen ook veel databases dit. 3.Ik wil uit mijn klantentabel de straat\plaats verwijderen en deze in een postcode tabel zetten (normaliseren dus). In mijn klantentabel hoef ik dan alleen de postcode op te slaan. Maar deze postcode dient te bestaan in mijn postcode tabel (anders heb ik geen straat/plaats). Dus ik dien, voordat ik een postcode invoer in mijn klantentabel, te controleren of de postcode al bestaat in de postcodetabel. Dit zou ik in mijn applicatie moeten doen? Is het niet handiger om dit de RDBMS te laten doen? Natuurlijk! Alleen RDBMS ondersteunen dit... MySQL niet.... 4.Ik wil dat als er een nieuwe postcode wordt ingevoerd in de klantentabel, er gecontroleerd word of deze voldoet (9999 AA-formaat) en automatische toegevoegd wordt aan de postcode tabel.Dit zou ik in mijn applicatie moeten doen? Is het niet handiger om dit de RDBMS te laten doen? Natuurlijk! en wat ingewikkeldere mogelijkheden... 5.Ik wil dat elke nieuw ingevoerde postcode automatische gecontroleerd wordt met het postcode boek van TPG-POST bv. via internet.Dit zou ik in mijn applicatie moeten doen? Is het niet handiger om dit de RDBMS te laten doen? Natuurlijk! 6.Ik wil dat elke 5 minuten van mijn database een backup wordt gemaakt en ik een waarschuwing per e-mail, sms krijg als dit mislukt.Dit zou ik in mijn applicatie moeten doen? Is het niet handiger om dit de RDBMS te laten doen? Natuurlijk! 7.Ik wil één bepaalde actie op de database terugdraaien, maar alle acties daarna zijn wel correct en dienen gewoon uitgevoerd te worden.Is het niet handiger als een RDBMS dit kan? Natuurlijk! 8.Ik heb meerdere applicaties die een klant kunnen toevoegen. Ik wil de structuur van de klantentabel aanpassen, zonder elke applicatie aan te hoeven passen.Is het niet handiger als een RDBMS dit kan? Natuurlijk! 9.Ik wil alle werknemers inzage geven in de details van andere werknemers, behalve het prive-adres en het salaris, ook al zou je de applicatie hacken (of zelf bouwen\programmeren) dan nog kun je niet het prive-adres of salaris van een andere werknemer opvragen.Is het niet handiger als een RDBMS dit kan? Natuurlijk! 10.etc, etc... Dit zijn een aantal voorbeelden, maar de strekking zal wel duidelijk zijn: Je kunt dus heel veel laten doen door je RDBMS, zonder dat je dit in elke applicatie dient te programmeren. Je applicatie wordt hierdoor veel 'lichter' en sneller en je kan makkelijker de database op ander manieren laten benaderen (bv. via internet) zonder bang te zijn dat je gegevens niet kloppen, immers je controles vinden plaats in de RDBMS, niet in de desbetreffende applicatie. Je hebt hiervoor een professionele DBA'er nodig om dit realiseren, bij voorkeur gespecialiseerd in de desbetreffende RDBMS (ben trouwens nog op zoek naar een nieuwe baan ;)). Als je een RDBMS volledig gebruikt (dus niet alleen voor het opslaan\ophalen van data), dan is het onmogelijk om deze te laten vervangen door MySQL, die geeneens relaties tussen tabbelen onderling ondersteunt. En als ik lees dat de topic-starter stored procedures gebruikt, dan is MySQL geen optie voor vervanging. Ben ook blij dat PHP MySQL niet meer standaard ondersteund (wat gezorgd heeft voor de bekendheid van MySQL), zodat PostgreySQL een kans krijgt en mensen realiseren wat een gemak een échte RDBMS je kan geven en het hopelijk meer keuze hebt bij hosting voor MySQL of PostgreSQL. -Rémy

Begrijp ik, maar óók al zou hij stukken goedkoper uit zijn qua licenties, met een andere RDBMS , dan denk ik dat de omzetting teveel geld zou kosten. Waarom? - Onderzoek: Je dient eerst alle mogelijkheden te onderzoeken (steek je nu al tijd in). Vervolgens dien je je gemaakte keuze verder te onderzoeken op obstakels bij de omzetting (denk o.a. aan drivers, datatypes met andere kenmerken, etc.); - Herschrijven: Aangezien je al je stored procedures, triggers, DTS's, etc. in T-SQL zijn geschreven, die je allemaal dient te gaan vertalen in een ander SQLdialect. Óók dien je alle applicaties die deze RDBMS gebruiken te controleren en delen te herschrijven\veranderen. - Nieuwe beperkingen: Elke RDBMS heeft zwakheden die in acht genomen dienen te worden. - Installatie en setupkosten Als ik dan kijk naar 100 tabbelen met waarschijnlijk veel data, veel Stored Procedures en de applicatie(s) die deze data gebruikt, dan denk ik dit zoiets toch wel een jaartje gaat duren voordat goed en correct is omgezet en getest is. En dit kost dus veel geld. Ik kan dit natuurlijk niet in deze situatie beoordelen, maar zo'n overstap doe je niet even snel tussendoor. Bedoelde inderdaad PostgreSQL ;D. Bij mij weten draait PostgreSQL nog niet native op Windows. Hiervoor is een extra layer nodig die unix emuleert: CygWin. En dit betekend performance-verlies en is daarom in mij ogen voor een productieomgeving nog niet geschikt. In versie 7.4 komt hopelijk wel native windowsondersteuning. Zie ook http://techdocs.postgresql.org/guides/Windows Ben ik met je eens, maar de reden dat ik het vroeg is om een inschatting te krijgen waarvoor de data gebruikt wordt (want als enkel voor een forum is, dan is de RDBMS niet goed opgebouwd) en dan kan ik ook een betere inschatting maken of overstappen laang gaat duren en veel geld gaat kosten. Waarom is MySQL geen serieuse vervanging voor SQLserver? Elke professionele DBA zou je uitlachen als je zou voorstellen om SQLserver\Oracle te vervangen door MySQL. Waarom? Omdat het twee verschillende producten zijn: MySQL is een database, SQLserver een RDBMS! Een RDBMS is je businesslogic. Dit kan alleen werken als deze basisdingen zoals foreign key's, views, stored procedures, triggers ondersteunt. MySQL ondersteund dit niet! Het zijn gewoon een paar losse tabellen zonder enige relatie tussen elkaar (zelfs MS Access doet dit beter)! Mocht het verschil tussen een database en een RDBMS nog niet duidelijk zijn, dan hoor ik het wel, want dan leg ik het wat uitvoeriger uit. -Rémy

Ik snap alleen niet waarom je van MSSQL afwil? Het is één van de beste database, dus waarom zou je willen overstappen als nu alles werkt. Vanuitgaande dat je écht meer dan 100 tabbellen heb en veel queries (en sp's) hebt, dan zou een overstap handen vol met tijd en geld kosten, die volgens mij nooit terug te verdienen zijn. (Ben toch wel benieuwd waarom je zoveel tabbellen nodig hebt...) En MySQL is geen serieuse vervanging kandidaat hiervoor. PostGrey misschien wel, maar dat werkt alleen op (l)unix. -Rémy