20. december 2004 - 11:01Der er
30 kommentarer og 2 løsninger
I gang med VS.NET og MS SQL
Hej.
Jeg har i flere år arbejdet professionelt i asp med access som database.
Nu er jeg så ved at flytte over til asp.net og det er gået pænt nok hvilket har givet mig blod på tanden. Jeg vil nu også gerne tage springet over til MS SQL meeeeeen....
Hvor skal jeg starte?
Jeg ved godt jeg kunne købe en masse bøger (har jeg faktisk gjort) men enten er de på et niveau hvor man skal læse 100 sider inden der er en linie som kommer med nyt eller også starter de så højt at man kun forstår halvdelen pga. manglende viden om nogle basale ting.
Håber der er en af jer der kan guide mig i den rigtige retning.
Den største grundlæggende forskel er, at MSSQL er en rigtig serverside database - modsat Access.
Det betyder at der er nogle driftsmæssige ting og begreber du skal have på plads; database backup hvordan og hvornår, transaktionslogning mv.
På SQL Server har du én master database som indholder metadata for alle andre databaser - inkl. brugerinformation. Dertil kommer en MSDB som indeholder job og historik information.
Du opretter nye databaser hvori dine brugerdata lægges. Hver af dem består af en række filer, typisk en MDF og LDF fil. Alle operationer i databasen skrives ned i LDF-filen (Database Transaction Log). Du skal vælge at tømme databaseloggen ved en backup (full recovery model) eller efter hver transaktion (simple recovery model).
Vælger du det sidste skal loggen kun indeholde plads til en transaktion, vælger du det første skal loggen indeholde plads til alle transaktioner mellem 2 backupper.
Fordelen ved full recovery er, at hvis din database bryder ned, eller du får sletteet data ved en fejl, så kan du genskabe databasen til et vilkårligt tidspunkt (point-in-time restore).
Backup skal ske via SQL Servers backup api - ikke ved en simpel filbackup. Du kan ikke genskabe en database hvis du ikke bruger den rigtige backup!
På MS' hjemmeside kan du downloade MSDE'en - det er en gratis letvægtsudgave af SQL Server som kan anvendes som backend til bl.a. Access. Bedre performance end Access men kunstigt begrænset til 5 samtidige forespørgsler og 2 GB data per brugerdatabase. God at få lidt indtryk af SQL Server med. Du kan også finde en webinterface til adm af en SQL Server.
Check lidt i de artikler jeg har i artikel sektionen vedr. sikkerhed på sql server. Det er ret vigtigt at få på plads.
Det er mere brug af MS SQL i stedet for access, der er jo rimelig forskel på om man benytter en 'filserver' database eller har klient-server mulighederne som i MS SQL.
Jeg bruger SQL i alle mine forespørgsler til Access i dag (ingen dataset osv.) så jeg ved hvordan man laver en SELECT, INSERT INTO eller UPDATE query. Så det er mere det at designe tabeller, views og stored procedures jeg mangler info om.
Mit setup er VS.NET 2003 og så MSDE på lokal maskine, jeg har ikke selv råd til en full MS SQL :-) men hvem ved, hvis jeg får det lært så kan det være jeg kan overtale min arbejdsgiver til at vi skal skippe Access og begynde at bruge MS SQL (vi er ved at nå Access's muligheder).
Som programmør bør du også have et vist indblik i anvendelse af log mv - det er dig der skal fortælle din administrator om det giver mening med point-in-time restore + dig der har ide om hvor aktiv basen er med opdateringer etc.
En anden ting er, at du bør designe hele dit database interface via stored procedures fremfor ad-hoc queries. Dermed sikrer du databasen mod indtrængen og får samtidig bedst mulig performance. Groft sagt - med stored procedures får du databasen som et stort objekt med en række metoder til datahåndtering. Den underliggende struktur er nu usynlig for applikationen som i en rigtig objektorienteret tankegang :-)
Jeg har i øvrigt også skrevet en række tuning artikler på sql server - netop rettet mod programmøreren (90% af al performancetuning består i at rette sql fra programører - de sidste 10% drejer sig om at rette i databasens opbygning og server opsætning... og måske er 10% sat for højt.. :-)
En SP implementering vil fx kunne fungere fint på både Oracle, SQL Server, Ingres og Sybase (faktisk vil Sybase stort set kunne anvende SQL Server implementeringen da begge bruger T-SQL). Eneste "udbredte" database der ikke kan klare det er vist egentlig MySQL - men det er reelt set også kun en serverimplementering af Paradox. En mere avanceret gratis database kan findes i Open Source databasen "Firebird"
Men allerede i og med designer sin database har man låst sig meget langt. Oracle har fx ikke forskellen med på tom streng og null - tilgengæld understøtter den triggere på before og after row & statement hvor SQL Server kun har "after statement" (instead of er en anden ting). MySQL har ingen procedurale dele, mangler metadata, funtkioner, procedurer og triggers - omend den åbenbart nu kan klare visse former for subqueries.
Ja - både Oracle og SQLServer har stored procedures.
Men du skal omskrive stored procedures fordi syntaxen er forskellig i Oracle og SQLServer.
Og du skal omskrive koden der kalder den stored procedure fordi SQLServer returnerer result sets uden om argumenterne/returværdi mens Oracle returnerer cursors i dem.
Det er dejligt at se at I gerne vil hjælpe mig og jeg har da også fået lidt på plads efter at have læst jeres kommentarer så tak for det.
Jeg har rimeligt fod på hvilke forskelle der skal tages hensyn til ved et skift fra Access til MS SQL.
Det jeg mangler viden om er design af databaser (tabeller, stored procedures, views mm.), og hvilke fælder man bør undgå. Man har jo en tendens til at vende sig til AutoIncrement i Access, men hvordan klare man den i MS SQL? Og er det i det hele taget smart? Og hvis ikke hvordan kommer man så uden om problemet hvis man ikke er interresseret i at bruge sammensatte nøgler til relationer?
Selvom jeg har benyttet access i mange år, og haft muligheden for at lave 'skod' databaser i den, så har jeg dog rettet en del af de ikke så heldige ting man jo har for vane at gøre men som på en SQL server ville være totalt 'no no'. Bl.a. at lade indput felter fra en web form indgå direkte i en SQL sætning. Der bruger jeg parametre nu i stedet.
Glemte lige at skrive at jeg godt kan li' at benytte mig af unikke værdier til mine relationer og til identifikation af mine objekter i databasen. I Access bruger jeg (simpelt skrevet) en tabel med et autoincrement felt(id) og et felt der kan tage et tal(data) jeg indsætter så et tilfældigt genereret tal i data og læser så hvilken id tabellen har givet tallet. Denne id bruger jeg så som mit unikke nummer. Det virker men jeg synes det er lidt besværligt og der findes garanteret en bedre måde at gøre det på på MS SQL.
Den metode du bruger der er vist ikke flerbruger sikker.
Brug AutoNumber (Access) eller IDENTITY (SQLServer) i de rigtige tabeller og fisk den indsatte værdi ud med @@IDENTITY eller SCOPE_IDENTITY() (den sidste kun i SQLServer).
Men flerbruger sikker vil jeg da mene min metode er, forudsat jeg sørger for at låse tabellen inden jeg opdatere. Og hvis jeg samtidigt sørger for at mit tilfældigt genererede tal ikke kun er tilfældigt men også indeholder en bruger id så 2 brugere ikke kan generere det samme tal på samme tid, hvilket ellers er usansynligt men dog muligt.
Det kan godt være at jeg ikke kan benytte metoden på en SQL server men i Access fungere den efter min overbevisning.
arne> Du har ret i at sp skal omskrives mellem de forskellige databaser - men det skal almindelig SQL også (fx specifik oracle syntax som DECODE vs CASE, join syntaks etc etc).
Min pointe er, at faktisk kan du ikke engang garentere at et givent applikations/database design fungerer på tværs af fx Oracle og SQL Server netop pga forskelle i NULL / tom streng, låsehåndtering etc.
Arne> Appropos cursors fra Oracle - det kan man sagtens komme udenom. Kort som jeg husker det: Lav en funktion der returnerer dine data og select den funktion fra dual.
Nej. Hvis man skriver database uafhængige applikationer, så nøjes man med et SQL subset som man regner med understøttes af alle de databaser man kan blive udsat for og ligger logikken i applikationen.
Jo. Med lidt forsigtig kodning kan det godt lade sig gøre.
Typisk vil man dog vælge noget eksternt persisterings software, som kender forskellige database dialekter.
Den slags bruger imidlertid normalt ikke stored procedures. Jeg har kigget på mange af den slags (J2EE CMP engines, diverse O/R mapping tools til Java og .NET) - og jeg mener kun at have set en enkelt som brugte stored procedures. Det er der sikkert en grund til.
I J2EE / Java verdenen sværger mange til at stored procedures og triggers skal holdes væk fra databaselaget - ofte er det de samme som mener at MySQL er en anvendelig database. Og MySQL understøtter jo heller ikke den slags ting hvad der nok er grunden...
I stort set alle systemer jeg kender til - og det er efterhånden ikke få i SQL Server og Oracle verdenen - anvendes der stored procedures / packages og triggers.
Det er faktisk en meget almindelig forteelse fra alle større software leverandører at basere sig på den slags - og jeg har da også set case værktøjer som har fin understøttelse af stored procedures, ligesom jeg har set værktøjer til automatisk migrering af netop disse ting mellem fx Oracle og SQL Server (omend de ikke var imponerende i kvalitet).
TSS lavede en survey sidste år for JDBC brug: 1. Oracle 37% 2. MySQL 17% 3. SQLServer 15% 4. DB2 14% 5. Sybase 7% 6. Informix 3%
Og for J2EE brug vil MySQL procenten være endnu lavere fordi InnoDB tabeller er ikke specielt meget brugte og MyISAM tabeller ikke kan bruges til J2EE).
Og med hensyn til din erfaring så må jeg jo spørge dig om du laver projekter eller produkter ?
Når man laver et projekt specifikt til en enkelt kunde, så er database uafhængighed sjældent et krav. Valg af database er et strategisk valg som er foretaget.
Men laver man et produkt som skal bruges hos 10, 100 eller 1000 kunder som har truffet deres forskellige valg af database, så er database uafhængighed pludselig en vigtig parameter.
Jeg har flere gange haft spørgsmålet herinde: datamtiker studerende XX er gået i gang med EJB'er og har lavet et eksempel efter en lærebog og kan ikke forstå hvorfor en EJBException ikke laver rollback på alle database ændringerne. Hvilken database ? MySQL. MyISAM tabeller ? Ja. Surprise surprise - EJB containeren kan ikke lave rollback når databasen ikke understøtter rollback.
Erfaring? Thja, Jeg er DBA og har arbejdet som det i ca 5 år - dvs. min vinkel er driftsvinklen og kendskabet er ikke til nogle få "egenudviklede" systemer men til (tilrettede) "standardsystemer" fra forskellige softwarehuse - og opgaverne er, bla. at flytte eksistenede systemer mellem databaseplatforme (når strategien ændres eller en kunde kræver et system skal køre på en ellers usupporteret databaseplatform), performance tuning, fejlsøgning og rådgivning til udviklere (alt fra normalisering og design til sql hjælp)...
Du har da ret i at databaseuafhængighed er en faktor i standardsystemer som fx SAP - deres løsning er så reelt at ignore relationsdatabasen og behandle data som et kæmpestort regneark hvad der databasemæssigt ikke er optimalt, men i andre systemer (f.x. i medicinalindustrien) vælger man lidt mere prosaisk at meddele kunden at de kan køre den og den databaseplatform hvis de ønsker at anvende systemet... og det gør kunden så...
En ting der lige skal nævnes med forskelle fra Access til MsSQl (arne var vistnok inde på det tidligere)- access tildeler defaults og autonumber værdi ved "begin transaction" hvorimod MsSQL gør det ved "commit". Det betyder at du ikke ser default værdier i applikationen uden at genindlæse en oprettet / ændret record.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
