mboost-dp1
Sun
Hvis i læser nyheden lidt grundigere vil i kunne se at det er den embedded version de har købt! og den skal installeres på kundens PC'er
Der skal ikke pilles ved den centrale DB2 på mainfraimen....
Jyske Bank Erhverv had previously been based on a proprietary database from Microsoft, and has now migrated onto MySQL Embedded Server. Jyske Bank entered into an OEM agreement with Sun Microsystems in order to embed and deploy MySQL within its online banking product, and benefit from 24/7 support from the vendor.
Der skal ikke pilles ved den centrale DB2 på mainfraimen....
Endelig begynder storspillerne at få øjnene op for at bare fordi man betaler kassen for noget er det ikke ens betydende med at det er det bedste :)"Det bedste" er et meget flydende begreb. Jeg bruger selv MySQL til meget, men når MyISAM's begrænsninger bliver et problem, så skal bestemt overveje om MySQL er det rigtige. Her skal det bruges som en del af noget klientsoftware og så er MySQL et ganske godt bud.
Der skal ikke pilles ved den centrale DB2 på mainfraimen....Nej, det tror jeg heller ikke at der er nogen der kunne drømme om. Og da især ikke at erstatte DB2 med MySQL. MySQL har bestemt rigtig mange styrker, men den er god til ca. det modsatte af DB2.
#4:
ja jeg tænkte også lige hvordan de ville skifte til MySQL der... selvom MySQL self har fået triggers, stored procedures etc. i version 5.0
men hvad skal de bruge det til hos kunden ? Altså hvilken type data skal de gemme hos kunden, som kræver en database ? og hvorfor overhovedet gennem data hos kunden (jeg formoder det ikke er fortrolige/konti informationer)?
ja jeg tænkte også lige hvordan de ville skifte til MySQL der... selvom MySQL self har fået triggers, stored procedures etc. i version 5.0
men hvad skal de bruge det til hos kunden ? Altså hvilken type data skal de gemme hos kunden, som kræver en database ? og hvorfor overhovedet gennem data hos kunden (jeg formoder det ikke er fortrolige/konti informationer)?
mathiass (6) skrev:"Det bedste" er et meget flydende begreb. Jeg bruger selv MySQL til meget, men når MyISAM's begrænsninger bliver et problem, så skal bestemt overveje om MySQL er det rigtige. Her skal det bruges som en del af noget klientsoftware og så er MySQL et ganske godt bud.
Der er jo også andre MySQL engines end MyISAM. InnoDB f.eks.
Holger_dk (7) skrev:
men hvad skal de bruge det til hos kunden ? Altså hvilken type data skal de gemme hos kunden, som kræver en database ? og hvorfor overhovedet gennem data hos kunden (jeg formoder det ikke er fortrolige/konti informationer)?
Artiklen nævner at det er er til Jyske Netbank Erhverv.
I modsætning en en normal netbank som jo oftest er en browserløsning er der her i erhvervsløsninger ofte tale om faktiske applikationer som kan kommunikere med banken. Store firmaer kan også have komplekse løsninger som evt. kan være integreret direkte i firmaets regnskabssystem.
Den slags kræver jo ofte at man kan gemme mange data ude hos kunden. F.eks. flere hundrede regninger som skal betales samme dag. Denne bunke af regninger sendes så til banken på en gang, men inden den sendes skal den jo opbevares et sted ude hos kunden. F.eks. i en mySQL database.
Der er jo også andre MySQL engines end MyISAM. InnoDB f.eks.Ja, men InnoDB er altså virkelig ikke ret hurtig. Jeg tror at 90% bruger MyISAM og hvis det ikke rækker, så bruger folk en helt anden db. Dog er der så absolut et marked for MyISAM, rigtig mange applikationer kan sagtens nøjes med MyISAM og hvad der følger med den af begrænsninger, men på en central server i en bank dur det altså ikke. Jyske Bank bruger MySQL til det helt rette formål her...
Nu skal man jo heller ikke glemme at MySQL jo Har deres gratis version (Man kan vel kalde den en slags public beta) der netop er gratis for at få en masse brugere til at gennemteste deres produkt. Derudover har de en række licens versioner der typisk ikke er den seneste version, men en gennemprøvet of fuldt suporteret udgave. (Og ja MySQL har en ganske glimrende support på disse produkter). Den embedded version anvendes i stor stil i industrien i dag (Danfoss er bla. en meget stor kunde hos MySQL)
#11
Tak... det var lige det jeg sad og tænkte.... Sådan generelt set har mange den fejlagtige opfattelse omkring produkter i freeware/open source kategorierne, at man står med håret i postkassen når det brænder på. Men faktum er jo at man kan købe sig til god og professionelt support, enten hos dem der udvikler softwaren, eller freelancere der er eksperter på området.
Jeg arbejder selv i en virksomhed der benytter FreeBSD/MySQL m.m., og vi har altid fået løst de issues vi har haft... Og så sparer vi SÅ mange penge fordi vi ikke skal købe/fornye licenser til dit og dat.
Tak... det var lige det jeg sad og tænkte.... Sådan generelt set har mange den fejlagtige opfattelse omkring produkter i freeware/open source kategorierne, at man står med håret i postkassen når det brænder på. Men faktum er jo at man kan købe sig til god og professionelt support, enten hos dem der udvikler softwaren, eller freelancere der er eksperter på området.
Jeg arbejder selv i en virksomhed der benytter FreeBSD/MySQL m.m., og vi har altid fået løst de issues vi har haft... Og så sparer vi SÅ mange penge fordi vi ikke skal købe/fornye licenser til dit og dat.
#11: MySQL er ikke gratis for Jyske Bank. Den gratis version er under GPL licens sammen med alle relevante drivere til den, så med mindre Jyske Bank vil udsende deres erhvervsprogrammer under GPL så skal der altså betales. Det er sådan set også fair nok. Den gratis version er sandelig ikke en beta, det er et færdigt og ekstremt stabilt produkt!
Der er ingen grund til at tro at de konkurrende produkter ikke er testet lige så godt. De fleste kommercielle databaser er klippestabile.
Der er ingen grund til at tro at de konkurrende produkter ikke er testet lige så godt. De fleste kommercielle databaser er klippestabile.
#15 Jeg tror der er noget du har misforstået.
Man kan sagtens anvende GPL versionen uden at skulle af med sin kildekode.
Jeg er ikke sikker på om det gælder for jyskebank i det her tilfælde, men eftersom de nok ikke bygger ret meget om i selve MySQL kunne de nok alligevel.
Så længer ens eget program kun sælges sammen med MySQL og altså bare opretter en forbindelse dertil, er der ingen krav om at denne software skal være udgivet under GPL.
Men du kan læse meget mere om det her:
http://www.xaprb.com/blog/2009/02/17/when-are-you-...
#11 Har sikkert ret i at den ikke er gratis for jyskebank, men det afhænger af om det piller ved MySQL eller de gemmer den væk inden i deres egen kilde.
Man kan sagtens anvende GPL versionen uden at skulle af med sin kildekode.
Jeg er ikke sikker på om det gælder for jyskebank i det her tilfælde, men eftersom de nok ikke bygger ret meget om i selve MySQL kunne de nok alligevel.
Så længer ens eget program kun sælges sammen med MySQL og altså bare opretter en forbindelse dertil, er der ingen krav om at denne software skal være udgivet under GPL.
Men du kan læse meget mere om det her:
http://www.xaprb.com/blog/2009/02/17/when-are-you-...
#11 Har sikkert ret i at den ikke er gratis for jyskebank, men det afhænger af om det piller ved MySQL eller de gemmer den væk inden i deres egen kilde.
#15
Vi bruger masser af open source på min arbejdsplads, det meste uden at betale for det. Vi udgiver nemlig ikke software, det vi laver bruger vi selv.
Men hvis vi laver en rettelse i noget OS (som er relevant for andre), mener jeg da vi plejer at sende et patch tilbage.
Vi bruger masser af open source på min arbejdsplads, det meste uden at betale for det. Vi udgiver nemlig ikke software, det vi laver bruger vi selv.
Men hvis vi laver en rettelse i noget OS (som er relevant for andre), mener jeg da vi plejer at sende et patch tilbage.
#16
Det link er et godt eksempel på hvordan man kan blive vildledt af information på internettet.
GPL licensen kræver at kode der linkes med GPL kode selv skal være GPL hvis man distribuerer til trediepart.
MySQL's GPL med FLOSS exception licens kræver at kode der linkes med deres kode skal være open source hvis man distribuerer til trediepart.
Hvis ikke man distribuerer sin kode til tredie part så er alt OK. Restriktionerne er derfor for software firmaer ikke for slutbruger firmaer.
Så langt er linket OK. Men nu kommer vi til det kritiske.
Det er helt essentielt at vi her skelner mellem database server koden og database client libraries koden.
For database server koden er licensen ikke et problem for langt de fleste. Man linker ikke sit program til databasen. Man connecter til den.
Det er kun i tilfælde af brug af MySQL som embedded database, at det kan blive et problem.
Problemet er at de bruger samme licens til database client libraries koden.
I mange tilfælde vil man nemlig have behov for at linke den med ind.
Ethvert firma som vil sælge software der bruger en MySQL database bør få en juridisk vurdering af licensens betydning for hvordan du bruger de libraries.
Som ikke-jurist er min fortolkning:
- PHP er ikke omfattet af reglen da mysql og mysqli extensions som er dem der er linket med client libraries er open source
- C/C++ vil være omfattet af reglen både ved statisk og dynamisk link med MySQL's libraries men ikke ved brug af ODBC da man kan skifte MySQL ud med en anden database via konfiguration
- Java vil være omfattet af reglen med hardcoded Class.forName og connection URL men ikke hvis de hentes fra konfigurations fil
- .NET vil være omfattet af reglen med brug af MySqlXxxx klasser men ikke ved brug af DB provider factory
Men stol ikke på min sunde fornuft men få en juridisk vurdering, hvis det er vigtigt.
Det link er et godt eksempel på hvordan man kan blive vildledt af information på internettet.
GPL licensen kræver at kode der linkes med GPL kode selv skal være GPL hvis man distribuerer til trediepart.
MySQL's GPL med FLOSS exception licens kræver at kode der linkes med deres kode skal være open source hvis man distribuerer til trediepart.
Hvis ikke man distribuerer sin kode til tredie part så er alt OK. Restriktionerne er derfor for software firmaer ikke for slutbruger firmaer.
Så langt er linket OK. Men nu kommer vi til det kritiske.
Det er helt essentielt at vi her skelner mellem database server koden og database client libraries koden.
For database server koden er licensen ikke et problem for langt de fleste. Man linker ikke sit program til databasen. Man connecter til den.
Det er kun i tilfælde af brug af MySQL som embedded database, at det kan blive et problem.
Problemet er at de bruger samme licens til database client libraries koden.
I mange tilfælde vil man nemlig have behov for at linke den med ind.
Ethvert firma som vil sælge software der bruger en MySQL database bør få en juridisk vurdering af licensens betydning for hvordan du bruger de libraries.
Som ikke-jurist er min fortolkning:
- PHP er ikke omfattet af reglen da mysql og mysqli extensions som er dem der er linket med client libraries er open source
- C/C++ vil være omfattet af reglen både ved statisk og dynamisk link med MySQL's libraries men ikke ved brug af ODBC da man kan skifte MySQL ud med en anden database via konfiguration
- Java vil være omfattet af reglen med hardcoded Class.forName og connection URL men ikke hvis de hentes fra konfigurations fil
- .NET vil være omfattet af reglen med brug af MySqlXxxx klasser men ikke ved brug af DB provider factory
Men stol ikke på min sunde fornuft men få en juridisk vurdering, hvis det er vigtigt.
#21, men hvis det med PHP passer kunne jeg jo bare skrive en meget tynd wrapper som linker til MySQL og er GPL. Så kunne jeg forbinde til min wrapper via en socket eller en TCP port eller hvor meget adskillelse der nu skal til før det er ok med GPL :-p.
Det lyder dog næsten for nemt.
Det lyder dog næsten for nemt.
#23
Hvis din wrapper er GPL, så er du lige vidt.
Der er ikke noget smuthul med GPL.
Der er et smuthul med GPL med FLOSS exception.
Fordi så kan du lave en wrapper der er open source således at den er OK med MySQL licensen men bruger en open source licens der ikke stiller krav til licens for den kaldende kode som GPL gør.
Det var imidlertid heller ikke frivilligt at MySQL lavede den FLOSS exception, men PHP truede med at droppe "samarbejde".
Så jeg mener at den er god nok.
Men jeg er ikke jurist med speciale i software licens ret.
I praksis tror jeg ikke at problemet er stå stort. Hvis MySQL er så vigtig for en at man gider udvikle sit eget lille wrapper component, så er man sandsynligvis også villig til at betale for en kommerciel licens og så få support på MySQL.
Hvis din wrapper er GPL, så er du lige vidt.
Der er ikke noget smuthul med GPL.
Der er et smuthul med GPL med FLOSS exception.
Fordi så kan du lave en wrapper der er open source således at den er OK med MySQL licensen men bruger en open source licens der ikke stiller krav til licens for den kaldende kode som GPL gør.
Det var imidlertid heller ikke frivilligt at MySQL lavede den FLOSS exception, men PHP truede med at droppe "samarbejde".
Så jeg mener at den er god nok.
Men jeg er ikke jurist med speciale i software licens ret.
I praksis tror jeg ikke at problemet er stå stort. Hvis MySQL er så vigtig for en at man gider udvikle sit eget lille wrapper component, så er man sandsynligvis også villig til at betale for en kommerciel licens og så få support på MySQL.
#25
A hva'? GPL er da en fin-fin licens, hvis du spørger mig. Der kan så være tilfælde hvor man ikke benytte andres source via GPL-licens, eller tilfælde hvor sourcen burde udgives med en anden licens.
BSD har jo sine tydelige problemer, du kan ikke bare sige at BSD-licens er bedre. Den er anderledes, og passer måske bedre til DIT behov.
Jeg kan selv bedst lige at benytte source under BSD-licensen, men som udgiver vil jeg måske foretrække GPL.
(Det eneste brugbare (for et væsentligt antal brugere) jeg faktisk har udgivet blev dog under BSD-licensen. Mest fordi jeg synes det var for simpelt til at beskytte alt for meget. Jeg overvejede public domain.)
A hva'? GPL er da en fin-fin licens, hvis du spørger mig. Der kan så være tilfælde hvor man ikke benytte andres source via GPL-licens, eller tilfælde hvor sourcen burde udgives med en anden licens.
BSD har jo sine tydelige problemer, du kan ikke bare sige at BSD-licens er bedre. Den er anderledes, og passer måske bedre til DIT behov.
Jeg kan selv bedst lige at benytte source under BSD-licensen, men som udgiver vil jeg måske foretrække GPL.
(Det eneste brugbare (for et væsentligt antal brugere) jeg faktisk har udgivet blev dog under BSD-licensen. Mest fordi jeg synes det var for simpelt til at beskytte alt for meget. Jeg overvejede public domain.)
#25
Forfatteren udgiver sin kode under den licens som han/hun foretrækker.
Det er deres ret.
Hvorvidt licensen er god for brugerne afhænger lidt af hvilken slags kode det er.
Som antydet ovenfor er der ikke mange som kan have noget imod at database serveren er under GPL.
Men man kan have noget imod at client libraries er det. Og jeg ved at der er software firmaer som ikke supporterer MySQL p.g.a. det.
Men det er jo MySQL's (nu SUN's) valg.
Det er lidt usædvaneligt med et library under GPL - LGPL ville være noget mere naturligt (eller en Apache/BSD). Men sådan skulle det altså ikke være.
Forfatteren udgiver sin kode under den licens som han/hun foretrækker.
Det er deres ret.
Hvorvidt licensen er god for brugerne afhænger lidt af hvilken slags kode det er.
Som antydet ovenfor er der ikke mange som kan have noget imod at database serveren er under GPL.
Men man kan have noget imod at client libraries er det. Og jeg ved at der er software firmaer som ikke supporterer MySQL p.g.a. det.
Men det er jo MySQL's (nu SUN's) valg.
Det er lidt usædvaneligt med et library under GPL - LGPL ville være noget mere naturligt (eller en Apache/BSD). Men sådan skulle det altså ikke være.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund