mboost-dp1
Hvilken database er din favorit?
Puha, mange forskellige gode og dårlige grunde, Personligt har jeg primært benyttet databaser sammen med Java. I modsætning til Internetudvikling kan man ikke være sikker på at ens brugere lige har en internetforbindelse, derfor bliver man nødt til at installere en database ved siden af når man installere et program, og det er jo noget "bøvl". Min stemme gik til MSAccess pga at den kan flyttes og ikke skal have en internetforbindelse/MSAccess installeret. Som Serious sagde er det egentlig ikke andet en en semikolonsepereret fil, men til gengæld en MEGET nem at håndtere semikolonseperaret fil.
Dertil kommer problemet så med at man skal ud og betale et par tusinde for en MSOffice pakke, men det er jo et helt andet problem :P
Dertil kommer problemet så med at man skal ud og betale et par tusinde for en MSOffice pakke, men det er jo et helt andet problem :P
#52: Access er faktisk slet ikke så teknisk dårlig igen, så det er ikke helt fair at kalde den en semikolonseperaret fil, flere af de databaser der er nævnt i listen er langt dårligere teknisk end Access. Problemet med Access ligger i at den er designet som en desktop database og dermed ikke yder den store performance eller kan klare ret mange millioner records, men det betyder ikke at den ikke fungerer ret så perfect til det formål den er skabt til, som bl.a. også er det du bruger den til :)
Synes også der mangler ADABAS. Jeg bruger denne database til dagligt, og må indrømme at jeg er væsentligt mere glad for at arbejde med den end MySQL (som jeg tidligere svor til) og MSSql. Det kan godt være den ikke har stored procedure, triggers og alt det andet nymodens stads, men den er ihvertfald hurtig at arbejde med. Men man behøver egentligt heller ikke stored procedures og triggers, hvis man bare skriver sine programmer ordentligt :)
#54 er adabas overhovedet en SQL database?
#55 stored procedures og alt den slags har egentligt først betydning når man taler om systemer med mange hetrogene klienter.
Hvis database og klient er samme program er der egentligt ikke brug for den slags, det er først når man ønsker at adskille Backend fra frontend at den slags bliver interesant.
ADABAS er så vidt jeg er informeret en database der i lighed med BerkeleyDB primært er beregnet til at blive embedet inde i en aplikation, og hertil er de begge vist ret suverene, der er IKKE tale om DRBMS-er.
Hvor Access kan værre tung skrøbelig og langsom har, berkeleyDB og ADABAS vist ikke det problem.
MSSQL oracle osv er ikke nødvendigvis skide meget mere effektive end systemer der ligger den slags uden om databasen, grunden til at det er smart at ligge det inden i databasen er at ACID giver en masse overhead pr transaktion, hvilket gør det til en smart ting at udføre så meget som mugligt pr transaktion.
#55 stored procedures og alt den slags har egentligt først betydning når man taler om systemer med mange hetrogene klienter.
Hvis database og klient er samme program er der egentligt ikke brug for den slags, det er først når man ønsker at adskille Backend fra frontend at den slags bliver interesant.
ADABAS er så vidt jeg er informeret en database der i lighed med BerkeleyDB primært er beregnet til at blive embedet inde i en aplikation, og hertil er de begge vist ret suverene, der er IKKE tale om DRBMS-er.
Hvor Access kan værre tung skrøbelig og langsom har, berkeleyDB og ADABAS vist ikke det problem.
MSSQL oracle osv er ikke nødvendigvis skide meget mere effektive end systemer der ligger den slags uden om databasen, grunden til at det er smart at ligge det inden i databasen er at ACID giver en masse overhead pr transaktion, hvilket gør det til en smart ting at udføre så meget som mugligt pr transaktion.
Dudsen:
Men man kan godt lave tingene uden stored procedure, dog kan man opnå sikkerhedsmæssige fordele ved brugen af stored procedures, men du kan klare dig ugen.
F.eks. er flere nyhedssites på nettet og dagbladenes, lavet på MySQL databaser, og de har rigeligt med individuelle clienter.
Men man kan godt lave tingene uden stored procedure, dog kan man opnå sikkerhedsmæssige fordele ved brugen af stored procedures, men du kan klare dig ugen.
F.eks. er flere nyhedssites på nettet og dagbladenes, lavet på MySQL databaser, og de har rigeligt med individuelle clienter.
Der er lige den detalje at Access ikke er en DB, men en GUI til MSJet databasen...
Og ja, Jet databasen var ret dårlig dengang den fulgte med Win95 ud på markedet (mener ikke den var med i 3.11), men den har udviklet sig kraftigt siden da. Det er ikke kun fordi at det give penge at den nu er i version 4.xxx
Derudover har den samme fordel som windows; Hvis man har Office (og jeg kender faktisk ikke nogen der har windows, men ikke office) så har man også en glimrende og relativt letanvendeligt DB-redskab, som selv min mor efterhånden kan finde ud af at bruge.
Dermed ikke være sagt at jeg ikke har brugt MySQL og PostgreSQL i forskellige sammenhænge. Det er bare ikke noget jeg gider arbejde med hvis jeg lige skal bruge en CV-database eller en oversigt over bon'er fra Bilka for det sidste halve år ;o)
Gæt selv hvor min stemme røg hen.
Og ja, Jet databasen var ret dårlig dengang den fulgte med Win95 ud på markedet (mener ikke den var med i 3.11), men den har udviklet sig kraftigt siden da. Det er ikke kun fordi at det give penge at den nu er i version 4.xxx
Derudover har den samme fordel som windows; Hvis man har Office (og jeg kender faktisk ikke nogen der har windows, men ikke office) så har man også en glimrende og relativt letanvendeligt DB-redskab, som selv min mor efterhånden kan finde ud af at bruge.
Dermed ikke være sagt at jeg ikke har brugt MySQL og PostgreSQL i forskellige sammenhænge. Det er bare ikke noget jeg gider arbejde med hvis jeg lige skal bruge en CV-database eller en oversigt over bon'er fra Bilka for det sidste halve år ;o)
Gæt selv hvor min stemme røg hen.
#55
Jeg har prøvet at lave komplekse systemer, og vedligeholder til dagligt systemer, der har i omegnen af 10-15.000 brugere.
Performance er kritisk, så selvom vi havde stored procedures og triggers er jeg ikke sikker på det ville blive benyttet i ret stor udstrækning alligevel. Hvad der måske gør mit scenarie lidt anderledes er at det hele foregår på mainframe, med tynde klienter.
#56 Ifølge manualen, så understøtter ADABAS SQL, men på mit arbejde benytter vi os ikke af det interface. Vi benytter det andet interface ADABAS benytter. Jeg har sandt at sige endnu ikke prøvet at lave SQL kald til ADABAS, da jeg ikke har haft behovet. Alle andre benytter også den anden måde at accesse databasen på, så det er vel bedst at holde programkoden homogen, så vi alle forstår koden 100%.
Hvis du med ebbedding mener at programkoden blandes direkte med selve database-kald-koden, har du ret. I ADABAS og Natural (som programmeringssproget vi benytter hedder) fisker man records direkte i progrmmaet. Dvs. man benytter ikke ODBC eller andet abstraktionslag. Programmeringssproget forstår silpelhen alle ADABAS kald og compiler dem.
Jeg har prøvet at lave komplekse systemer, og vedligeholder til dagligt systemer, der har i omegnen af 10-15.000 brugere.
Performance er kritisk, så selvom vi havde stored procedures og triggers er jeg ikke sikker på det ville blive benyttet i ret stor udstrækning alligevel. Hvad der måske gør mit scenarie lidt anderledes er at det hele foregår på mainframe, med tynde klienter.
#56 Ifølge manualen, så understøtter ADABAS SQL, men på mit arbejde benytter vi os ikke af det interface. Vi benytter det andet interface ADABAS benytter. Jeg har sandt at sige endnu ikke prøvet at lave SQL kald til ADABAS, da jeg ikke har haft behovet. Alle andre benytter også den anden måde at accesse databasen på, så det er vel bedst at holde programkoden homogen, så vi alle forstår koden 100%.
Hvis du med ebbedding mener at programkoden blandes direkte med selve database-kald-koden, har du ret. I ADABAS og Natural (som programmeringssproget vi benytter hedder) fisker man records direkte i progrmmaet. Dvs. man benytter ikke ODBC eller andet abstraktionslag. Programmeringssproget forstår silpelhen alle ADABAS kald og compiler dem.
MySQL har sin plads i visse sammenhænge, men alle, der overvejer at benytte MySQL til blot noget nogenlunde seriøst bør på forhånd have kigget nærmere på http://sql-info.de/mysql/gotchas.html
#56
[stored procedures og alt den slags har egentligt først betydning når man taler om systemer med mange hetrogene klienter.]
Der er masser af fordele ved at bruge triggers, stored procedures, functions osv selv i løsninger med få ens klienter. Så den påstand må du meget gerne argumentere for.
Fordele uanset antal/type:
* DB logik fjernes fra klienter
* Performance
* Sikkerhed
[stored procedures og alt den slags har egentligt først betydning når man taler om systemer med mange hetrogene klienter.]
Der er masser af fordele ved at bruge triggers, stored procedures, functions osv selv i løsninger med få ens klienter. Så den påstand må du meget gerne argumentere for.
Fordele uanset antal/type:
* DB logik fjernes fra klienter
* Performance
* Sikkerhed
Hvis nogen bruger mysql til andet en et lamt sql interface til b0rken tekst filer så burde de få hjernen undersøgt. MySQL har intet med en SQL-database at gøre ud over at navnet indeholder SQL.
Til dem der mener stored procedures ikke er nødvendige syntes jeg de skulle læse lidt om database-design, interfacing og performance.
Desuden performer en korrekt opsat postgresql ca. på samme niveau som en mysql. Denne kan desuden oftest optimeres betydeligt bedre end mysql.
Til dem der mener stored procedures ikke er nødvendige syntes jeg de skulle læse lidt om database-design, interfacing og performance.
Desuden performer en korrekt opsat postgresql ca. på samme niveau som en mysql. Denne kan desuden oftest optimeres betydeligt bedre end mysql.
#56 DUdsen:
Du behøver ikke at spille dum - det er du jo ikke.
Det er logisk, at jeg referer til brugen af en ekstern database i sammenhæng med trådens emne. Læs mit indlæg udfra en bevidsthed om kontekst, og ikke hvor du blot forsøger at udpensle de fejl, der kan være, hvis du splitter det til atomer.
#59 starfish:
At et system har mange brugere, betyder ikke nødvendigvis at det er kompleks.
Du behøver ikke at spille dum - det er du jo ikke.
Det er logisk, at jeg referer til brugen af en ekstern database i sammenhæng med trådens emne. Læs mit indlæg udfra en bevidsthed om kontekst, og ikke hvor du blot forsøger at udpensle de fejl, der kan være, hvis du splitter det til atomer.
#59 starfish:
At et system har mange brugere, betyder ikke nødvendigvis at det er kompleks.
MSSQL og Acces er nu udmærket til at øve sig med, synes jeg. Kender ikke MySQL, men bliver det næste jeg kaster mig ud i.
Har hørt at Oracle skulle være mest anvendt i de profesionelle kredse og at der findes lange kurser (ca. 2 år) til dét alene.
Har hørt at Oracle skulle være mest anvendt i de profesionelle kredse og at der findes lange kurser (ca. 2 år) til dét alene.
#63
Du har ret i at menge brugere ikke nødvendigvis betyder at systemerne er komplekse. :) Jeg har bare lidt svært ved at define hvad "komplekse systemer" er og jeg er sikker på at vi ikke har samme opfattelse af hvad det er. De systemer jeg arbejder med til dagligt er meget komplekse (efter min mening). Kompleksisteten består i at hele vores program portefølge er udviklet over en periode på 15-20 år. Dette indebærer at mange af programmerne ikke er programmeret efter nutidens trend, og forretnings- og applikationsmodeller er der ikke altid noget af. Så det komplekse består efter min mening af at analysere konsekvenserne af ændringnsønsker fra brugerne.
Så teoretisk er stored procedures/triggers sikkert ok, men i praksis ville vi ikke kunne benytte os af det uden vidtgående omstruktureringer, analyser etc. Og så er der alligevel meget andet der kunne hjælpe os endnu bedre for den samme sum penge, som det nu måtte koste.
Du har ret i at menge brugere ikke nødvendigvis betyder at systemerne er komplekse. :) Jeg har bare lidt svært ved at define hvad "komplekse systemer" er og jeg er sikker på at vi ikke har samme opfattelse af hvad det er. De systemer jeg arbejder med til dagligt er meget komplekse (efter min mening). Kompleksisteten består i at hele vores program portefølge er udviklet over en periode på 15-20 år. Dette indebærer at mange af programmerne ikke er programmeret efter nutidens trend, og forretnings- og applikationsmodeller er der ikke altid noget af. Så det komplekse består efter min mening af at analysere konsekvenserne af ændringnsønsker fra brugerne.
Så teoretisk er stored procedures/triggers sikkert ok, men i praksis ville vi ikke kunne benytte os af det uden vidtgående omstruktureringer, analyser etc. Og så er der alligevel meget andet der kunne hjælpe os endnu bedre for den samme sum penge, som det nu måtte koste.
- Forside
- ⟨
- Forum
- ⟨
- Afstemninger
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
- ⟨
- Afstemninger
Gå til bund