Avatar billede nazaq Nybegynder
20. december 2004 - 11:01 Der 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.
Avatar billede arne_v Ekspert
20. december 2004 - 11:15 #1
Hvis du har lært ASP.NET så bør der ikke være mange ben i at skifte
fra Access til SQLServer.

Sådan groft sagt hedder klasserne SqlXxxx fremfor OleDbxxxx.

Eller er det brug af database i ASp.NET generelt du savner info om ?
Avatar billede trer Nybegynder
20. december 2004 - 11:24 #2
Du får lige nogle pointers:

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.
Avatar billede nazaq Nybegynder
20. december 2004 - 11:25 #3
Hej Arne

Programmeringen har jeg helt fod på :-)

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).
Avatar billede arne_v Ekspert
20. december 2004 - 11:27 #4
Så skal du nok læse lidt på trer's indlæg
Avatar billede nazaq Nybegynder
20. december 2004 - 11:31 #5
Hej Trer

Tak skal du have for info.

Jeg skal ikke administrere en MS SQL server men mere benytte mig af den set fra en programmør's synspunkt.
Avatar billede trer Nybegynder
20. december 2004 - 16:21 #6
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.. :-)

Mvh
Troels
Avatar billede arne_v Ekspert
20. december 2004 - 16:27 #7
Hvorvidt man skal satse på stored procedures eller ej er ikke helt så simpelt.

Det giver fordele med performance, security og encapsulation. Men man
binder sig også til en bestemt database.

Hvis database uafhængighed er et krav, så er stored procedures ikke vejen frem.
Avatar billede trer Nybegynder
20. december 2004 - 23:09 #8
Arne > Du har delvist ret, men kun delvist.

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.
Avatar billede arne_v Ekspert
20. december 2004 - 23:54 #9
Nej.

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 meget langt fra database uafhængighed.
Avatar billede nazaq Nybegynder
21. december 2004 - 09:45 #10
Hej igen i to

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.
Avatar billede nazaq Nybegynder
21. december 2004 - 09:54 #11
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.
Avatar billede arne_v Ekspert
21. december 2004 - 10:23 #12
SQLServer har IDENTITY som svarer pænt til Access AutoNumber.
Avatar billede arne_v Ekspert
21. december 2004 - 10:25 #13
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).
Avatar billede nazaq Nybegynder
21. december 2004 - 10:38 #14
Helt fint.

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.
Avatar billede arne_v Ekspert
21. december 2004 - 11:23 #15
Hvis du har tabellen låst under både INSERT + SELECT + ny INSERT, så er det
naturligvis sikkert.

Men det er næppe godt for performance.
Avatar billede trer Nybegynder
21. december 2004 - 16:29 #16
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.
Avatar billede trer Nybegynder
21. december 2004 - 16:30 #17
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.
Avatar billede arne_v Ekspert
21. december 2004 - 16:52 #18
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.
Avatar billede trer Nybegynder
21. december 2004 - 23:00 #19
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).
Avatar billede arne_v Ekspert
21. december 2004 - 23:11 #20
????

MySQL er ikke typisk i J2EE verdenen !

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).

Så den forstår jeg ikke.
Avatar billede arne_v Ekspert
21. december 2004 - 23:14 #21
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.
Avatar billede trer Nybegynder
21. december 2004 - 23:18 #22
Hmm.. ok, det var blot det indtryk jeg havde - så "I stand corrected" hvad angår anvendelsen af MySQL...
Avatar billede arne_v Ekspert
21. december 2004 - 23:27 #23
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.
Avatar billede trer Nybegynder
21. december 2004 - 23:41 #24
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å...
Avatar billede trer Nybegynder
21. december 2004 - 23:42 #25
Angående MySQL - faktisk er jeg ganske overrasket over dens udbredelse når man sammenligner dens funktionalitet og mangler med fx Firebirds...
Avatar billede arne_v Ekspert
21. december 2004 - 23:50 #26
1)  god PR (alle kender MySQL - kun fagfolk kender PostgreSQL og Firebird)

2)  god performance fordi der ingen log er

3)  utroligt mange praktiske funktioner

4)  den gennemsnitlige hjemme side programmer har aldrig hørt om transaktioner
    eller stored procedures
Avatar billede nazaq Nybegynder
03. januar 2005 - 14:48 #27
Hvad med points? Vil I dele dem så skriv lige et svar :-)
Avatar billede arne_v Ekspert
03. januar 2005 - 18:21 #28
ok
Avatar billede trer Nybegynder
03. januar 2005 - 22:42 #29
Også ok herfra.

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.
Avatar billede veronica Nybegynder
04. januar 2005 - 08:43 #30
Meget interessant diskussion :-)

Troels: De der performance artikler du nævner - har du et link til dem ?? Det lyder meget interessant.
Avatar billede arne_v Ekspert
04. januar 2005 - 08:46 #31
Avatar billede nazaq Nybegynder
04. januar 2005 - 19:50 #32
Tak for hjælpen
Avatar billede Ny bruger Nybegynder

Din løsning...

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.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester