mboost-dp1

unknown
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
"og der opfordres til at basere alt ny database udvikling, på denne version."
Og jeg der lige har udviklet til PostGreSQL, faens også!
(Der jokes)
Og jeg der lige har udviklet til PostGreSQL, faens også!
(Der jokes)
Uha, det er lækkert.
Efter 3 års ventetid, er der endelig en ny major-version af MySQL.
Nu mangler den bare at komme i portage, hvor der lige nu kun ligger en hard-masked 5.0.12_beta, og ikke RC'en. :)
Jeg er lykkelig! :D
Efter 3 års ventetid, er der endelig en ny major-version af MySQL.
Nu mangler den bare at komme i portage, hvor der lige nu kun ligger en hard-masked 5.0.12_beta, og ikke RC'en. :)
Jeg er lykkelig! :D
Hmm. Før min webhoteludbyder skifter til det har jeg dog ikke tænkt mig at skifte. :)
EDIT: Hmm. Det er vel egentlig kompatibelt.. Men nu vil jeg lige gå ud og finde ud af hvad en ANSI standard er for noget. :)
EDIT: Hmm. Det er vel egentlig kompatibelt.. Men nu vil jeg lige gå ud og finde ud af hvad en ANSI standard er for noget. :)
uhh nice :)
Nu er mysql virkelig ved at nå op på højde med mere prof. databaser.
Specielt Stored Procedures, og Triggers er nice. Så kan vi lade MySQL gøre endnu mere af det træls arbejde.
Så mangler man næsten bare at der udvikles nogle bedre version af phpmyadmin (som er alt for ofte brugt på webhoteller), til at håntere alle disse nye features :D
Nu er mysql virkelig ved at nå op på højde med mere prof. databaser.
Specielt Stored Procedures, og Triggers er nice. Så kan vi lade MySQL gøre endnu mere af det træls arbejde.
Så mangler man næsten bare at der udvikles nogle bedre version af phpmyadmin (som er alt for ofte brugt på webhoteller), til at håntere alle disse nye features :D
Da lækkert nok at den efterhånden kommer med, men jeg har svært ved at se argumentet for at man ikke skulle benytte databaser som PostgreSQL eller Firebird der har haft disse features i årevis og mere til.
Disse er tilmed tilgængelige under BSD licensen der er langt mindre restriktiv end MySql's licenseringsmuligheder - især i forhold til commercielt brug.
Disse er tilmed tilgængelige under BSD licensen der er langt mindre restriktiv end MySql's licenseringsmuligheder - især i forhold til commercielt brug.
#10 "Hvad er Triggers, Views og Stored Procedures?"
Triggers = sql / kode der udføres når en betingelse sker, f.eks. når tabellen opdaters.
View = en "falsk" tabel der kun kan skrives til, et gemt SELECT statement.
Stored Procedures = sql / kode der kan kaldes fra triggers, views ( så må de dog ikke modificerer noget ) eller fra alm sql kald. basielt set fungere der som en function der ikke kan retunerer noget. er praktisk hvis man ofter laver de(n) samme sql kald da DBMSen som oftest kan optimere det og derved spare dig tid.
ovenstående er baseret på hvordan det virker i MSSQL, men det er næppe markant forskelligt
Triggers = sql / kode der udføres når en betingelse sker, f.eks. når tabellen opdaters.
View = en "falsk" tabel der kun kan skrives til, et gemt SELECT statement.
Stored Procedures = sql / kode der kan kaldes fra triggers, views ( så må de dog ikke modificerer noget ) eller fra alm sql kald. basielt set fungere der som en function der ikke kan retunerer noget. er praktisk hvis man ofter laver de(n) samme sql kald da DBMSen som oftest kan optimere det og derved spare dig tid.
ovenstående er baseret på hvordan det virker i MSSQL, men det er næppe markant forskelligt
nummer #10 Det er en slags funktioner som du ligger ind i din database..
F.eks. kan du lave et View som hedder "Vis_Alt" og når du kører denne udføre den noget sql kode som du selv har defineret.
Så i stedet for at have alt sql koden til at stå i et php script f.eks. så kan du bare kalde en SQL procedure eller view fra php koden.
F.eks. kan du lave et View som hedder "Vis_Alt" og når du kører denne udføre den noget sql kode som du selv har defineret.
Så i stedet for at have alt sql koden til at stå i et php script f.eks. så kan du bare kalde en SQL procedure eller view fra php koden.
Endelig.. Views mangler jeg temmelig meget i MySQL 4.0, som UnoEuro kører med. Men jeg har lige spurgt og fik et svar (på 6 minutter), hvori de siger at de vil installere denne nye version når den bliver "production stable"..
Er der nogen der har en ide om hvornår det bliver? Hvornår plejer sådan noget at gå fra en release candidate til en production stable udgave? Og hvad er det værste man kan forvente..? 5 år eller hva? :oP
Er der nogen der har en ide om hvornår det bliver? Hvornår plejer sådan noget at gå fra en release candidate til en production stable udgave? Og hvad er det værste man kan forvente..? 5 år eller hva? :oP
Lækkert.. nu er jeg ikke die-hard databaseguru, men stored procedures er noget jeg har ventet længe på.
#4: Jeg så hellere at man undgik phpMyAdmin og så i stedet fik lov at logge på via en ekstern forbindelse. Men det er nok et spørgsmål om sikkerhed
OT: Hvornår mon de forskellige webhoteller begynder at opgradere til PHP5?
#4: Jeg så hellere at man undgik phpMyAdmin og så i stedet fik lov at logge på via en ekstern forbindelse. Men det er nok et spørgsmål om sikkerhed
OT: Hvornår mon de forskellige webhoteller begynder at opgradere til PHP5?
#14 - Ja, det er bagud kompatibelt.
#15 - Jo tak, php5 vil vi gerne ha :D exceptions <3
mht. at undgå phpmyadmin, ville jeg også gerne det samme, men webhotellerne finder der stadig mest sikkert at bruge phpmyadmin via. localhost (dermed er bruteforce gjort lidt sværere).
Anyway, det bedste i webdev med stored procedure , ville være ting som ændring af data, f.eks. en dato, til et andet format, uden at skulle skrive endeløse SQL kommandoer til det ihver eneste SELECT statement.
#15 - Jo tak, php5 vil vi gerne ha :D exceptions <3
mht. at undgå phpmyadmin, ville jeg også gerne det samme, men webhotellerne finder der stadig mest sikkert at bruge phpmyadmin via. localhost (dermed er bruteforce gjort lidt sværere).
Anyway, det bedste i webdev med stored procedure , ville være ting som ændring af data, f.eks. en dato, til et andet format, uden at skulle skrive endeløse SQL kommandoer til det ihver eneste SELECT statement.
¤5 Sguft
Da MySQL er GPL licenseret, så må du naturligvis også bruge den kommercielt. Alt andet ville nemlig være GPL stridigt. Frihederne omkring distribution ændret eller uændret kræver, at både kommercielt og ukommercielt er tilladt. Så jeg er lidt forvirret over hvad du mener?.
#13
Vist afhængigt af hvor mange som hjælper dem med at luge fejl ud fra den her?... ;) *HINT*
Da MySQL er GPL licenseret, så må du naturligvis også bruge den kommercielt. Alt andet ville nemlig være GPL stridigt. Frihederne omkring distribution ændret eller uændret kræver, at både kommercielt og ukommercielt er tilladt. Så jeg er lidt forvirret over hvad du mener?.
#13
Vist afhængigt af hvor mange som hjælper dem med at luge fejl ud fra den her?... ;) *HINT*
jeg kan nu godt lide mysql - jeg ved godt postgresql har mange flere features, men den er langt mere besværlig - mysql skal bare installeres og så virker den.
#18
Jeg synes nu ikke, at PostgreSQL er sværere at komme i gang med end MySQL. Den har mange flere avancerede features, så det tager selvfølgelig længere tid at lære alt om systemet. Men det basale er det samme: installér, start serveren, opret en bruger, opret en database, hack-away :) Måske kunne du uddybe, hvad du mener?
Jeg synes nu ikke, at PostgreSQL er sværere at komme i gang med end MySQL. Den har mange flere avancerede features, så det tager selvfølgelig længere tid at lære alt om systemet. Men det basale er det samme: installér, start serveren, opret en bruger, opret en database, hack-away :) Måske kunne du uddybe, hvad du mener?
#20
Så skal du jo så lige huske på at Postgresql ikke er gratis til kommercielt brug, omend det ligger udenfor diskussionen så er det værd at bemærke, det betyder at til alt kommercielt brug skal du, hvis du udvikler på produktet, videregive et vist beløb om alle omstændigheder.
At det så også er fint nok er så noget andet, men det er værd at bide mærke i.
Så skal du jo så lige huske på at Postgresql ikke er gratis til kommercielt brug, omend det ligger udenfor diskussionen så er det værd at bemærke, det betyder at til alt kommercielt brug skal du, hvis du udvikler på produktet, videregive et vist beløb om alle omstændigheder.
At det så også er fint nok er så noget andet, men det er værd at bide mærke i.
#21
Hvor har du fået at vide, at PostgreSQL ikke er gratis til kommercielt brug? Det har jeg ihvertfald aldrig hørt om. Fra deres egen side:
Best of all, PostgreSQL's source code is available under the most liberal open source license: the BSD license. This license gives you the freedom to use, modify and distribute PostgreSQL in any form you like, open or closed source. Any modifications, enhancements, or changes you make are yours to do with as you please.
Måske forveksler du det med MySQL AB's dual-licensing?
Hvor har du fået at vide, at PostgreSQL ikke er gratis til kommercielt brug? Det har jeg ihvertfald aldrig hørt om. Fra deres egen side:
Best of all, PostgreSQL's source code is available under the most liberal open source license: the BSD license. This license gives you the freedom to use, modify and distribute PostgreSQL in any form you like, open or closed source. Any modifications, enhancements, or changes you make are yours to do with as you please.
Måske forveksler du det med MySQL AB's dual-licensing?
For lige at skære igennem alt det pjat om GPL vs BSD på disse projekter:
MySQL er licenseret under GPL, som SIKRE at både kommercielt og ukommercielt brug, er komplet tilladt.Dette kan MySQL AB IKKE, gentager IKKE gradbøje på nogen måde. Det MySQL AB gør er, at muliggøre det for firmaer at betale sig fra deres pligter. Dvs overhold GPL, eller betal for en version under en licens vi forhandler os frem til. Dette er naturligvis dybt beklageligt, at man kan betale sig fra den slags. Men det er i bund og grund hvad der er tale om.
BSD licenseret software kan sjovtnok heller ikke i sig selv, indeholde begrænsninger af nogen art. PostgreSQL kan derfor ikke først give folk lov til alt, og så tage det tilbage andetsteds. Ved ikke hvordan folk har fået den idé.
Når dette er sagt, så stør endelig disse projekter økonomisk, hvis i har glæde af dem.
#20 Sguft
På kort sigt ja.
Denne ekstra frihed er desværre til mere ulempe end gavn. GPL licensens resfriktion er jo til for at sikre, at softwaren forbliver fri uanset hvor du modtager den. Lavet i erkendelse af, at ikke alle har lige hæderlige intentioner med koden.
MySQL er licenseret under GPL, som SIKRE at både kommercielt og ukommercielt brug, er komplet tilladt.Dette kan MySQL AB IKKE, gentager IKKE gradbøje på nogen måde. Det MySQL AB gør er, at muliggøre det for firmaer at betale sig fra deres pligter. Dvs overhold GPL, eller betal for en version under en licens vi forhandler os frem til. Dette er naturligvis dybt beklageligt, at man kan betale sig fra den slags. Men det er i bund og grund hvad der er tale om.
BSD licenseret software kan sjovtnok heller ikke i sig selv, indeholde begrænsninger af nogen art. PostgreSQL kan derfor ikke først give folk lov til alt, og så tage det tilbage andetsteds. Ved ikke hvordan folk har fået den idé.
Når dette er sagt, så stør endelig disse projekter økonomisk, hvis i har glæde af dem.
#20 Sguft
På kort sigt ja.
Denne ekstra frihed er desværre til mere ulempe end gavn. GPL licensens resfriktion er jo til for at sikre, at softwaren forbliver fri uanset hvor du modtager den. Lavet i erkendelse af, at ikke alle har lige hæderlige intentioner med koden.
Gode nyheder, bliver især rart med de tre main features nævnt ovenfor. Og ikke mindst at MySQL kommer til at følge 'den rigtige' standard..
Desværre må man erkende, at de billige danske webhoteller er ret langsomme til at opgradere deres servere. Det er i hvert fald min erfaring, da ingen af de tre billige hoteller, jeg bruger til privat brug har skiftet fra PHP4 endnu. *suk*
Desværre må man erkende, at de billige danske webhoteller er ret langsomme til at opgradere deres servere. Det er i hvert fald min erfaring, da ingen af de tre billige hoteller, jeg bruger til privat brug har skiftet fra PHP4 endnu. *suk*
#27 nej egentligt ikke.
man kan vel godt beskrive det gemte select statement some en procedure ( dette skaber bare forvirring da der faktisk ER gemte procedure - stored procedures )
Fordelen ved den "falske" tabel der kun kan skrive til ( et view ) er at du kan give rettigheder til view'et uafhængigt af hvadde underlæggende tabeller har af rettigheder.
Med andre ord kan man tillade program X kun at se view'et så de ikke har adgang til de tabeller view'et skabes af ( som måske indeholde andre oplysninger du ikke ønsker skal kunne tilgås ved etc evt. injection attack )
der kan være en række andre fordele men det afhænger af implementationen ( chaching mm ) og jeg har ikke sat mig ind i hvordan det er lavet i MySql endnu
man kan vel godt beskrive det gemte select statement some en procedure ( dette skaber bare forvirring da der faktisk ER gemte procedure - stored procedures )
Fordelen ved den "falske" tabel der kun kan skrive til ( et view ) er at du kan give rettigheder til view'et uafhængigt af hvadde underlæggende tabeller har af rettigheder.
Med andre ord kan man tillade program X kun at se view'et så de ikke har adgang til de tabeller view'et skabes af ( som måske indeholde andre oplysninger du ikke ønsker skal kunne tilgås ved etc evt. injection attack )
der kan være en række andre fordele men det afhænger af implementationen ( chaching mm ) og jeg har ikke sat mig ind i hvordan det er lavet i MySql endnu
#30
Jeg kan ikke se den store forskel, både MySQL og PostgreSQL har konfigurationsfiler, men med mindre du vil tune nogle indstillinger, så kører de begge fint med deres default konfiguration. Hvis jeg vil lave en database samt en bruger på henholdsvis MySQL og PostgreSQL på min maskine, så gør jeg følgende med MySQL:
mysql -p root
Password: *******
mysql > CREATE DATABASE mydb;
mysql > GRANT ALL ON mydb TO 'blinklys'@'localhost' IDENTIFIED BY 'password';
mysql > \q
Og med PostgreSQL:
su - pgsql
createdb mydb
psql mydb
mydb=# CREATE USER blinklys PASSWORD 'password';
mydb=# GRANT ALL ON DATABASE mydb TO blinklys;
mydb=# \q
... synes ikke der er den store forskel.
Jeg kan ikke se den store forskel, både MySQL og PostgreSQL har konfigurationsfiler, men med mindre du vil tune nogle indstillinger, så kører de begge fint med deres default konfiguration. Hvis jeg vil lave en database samt en bruger på henholdsvis MySQL og PostgreSQL på min maskine, så gør jeg følgende med MySQL:
mysql -p root
Password: *******
mysql > CREATE DATABASE mydb;
mysql > GRANT ALL ON mydb TO 'blinklys'@'localhost' IDENTIFIED BY 'password';
mysql > \q
Og med PostgreSQL:
su - pgsql
createdb mydb
psql mydb
mydb=# CREATE USER blinklys PASSWORD 'password';
mydb=# GRANT ALL ON DATABASE mydb TO blinklys;
mydb=# \q
... synes ikke der er den store forskel.
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.