Jobb database med SQL

[G2Petter]

Bare så du er klar over det: One.com har ikke (sist jeg sjekket, i det minste,) støtte for InnoDB.

[DanOve]

Ellers finnes det mange ferdige programmer som har alle de funksjoner trådstarter spesifiserer, og mer til. Hvorfor finne opp hjulet på nytt?

 

Werner

 

det er for å slå to fluer i en smekk.

jeg ønsker å lære meg dette og at jeg trenger noe slikt. så hvorfor ikke prøve.

'

basen skal inne holde Kunde opplysninger....

 

har ikke one.com det?

hmm da setter jeg opp en egen server.

tanken var at hvem som helst i firma kunne legge inn oppdrag som de mottar uansett hvor de er og bare ha nett tilgang.

[blackbrrd]

Hvis du skal sette opp din egen server hadde jeg gått for postgresql

 

http://www.postgresql.org

[DanOve]

Hvis du skal sette opp din egen server hadde jeg gått for postgresql

 

http://www.postgresql.org

 

takk for tipset

[blackbrrd]

Liker veldig godt create table syntaxen som du kan bruke når du oppretter tabeller i postgresql:

 

CREATE TABLE kunde (
 kundeid serial primary key,
 kundenavn text
);

CREATE TABLE oppdrag (
 oppdragid serial primary key,
 id_kundeid integer references kunde,
 oppdragnavn text
);

 

Serial vil si at tabellen får autonummer som øker med en som default.

Primary key vil logisk nok si at det blir opprettet en primary key på feltet.

References sier at feltet er en foreign key til primary key-en i tabellen den peker på.

[JohndoeMAKT]

MySQL kan kjøres med to motorer i bunn: MyISAM og og InnoDB.

Og Memory, Archive, Merge, Federated, CSV, Blackhole, Falcon, Cluster, BDB, EXAMPLE, Maria, solidDB, NitroEDB, BrightHouse, memcached, httpd, PBXT og sikkert flere non-public motorer da motoren er en separat del du kan skrive selv og plugge inn.

 

har ikke one.com det?

hmm da setter jeg opp en egen server.

Det er ingen vits å gå bort fra one.com bare fordi de ikke støtter InnoDB. MyISAM er kjempe den, styggfort på enkle spørringer med ikke for store tabeller ( helst med enten mye skriving eller mye lesing ) og støtter f.eks mysqlhotcopy. Fordelene blackbrrd nevner med InnoDB er selvsagt der, men jeg har veldig vanskelig for å tro at det vil ha noen påvirkning på deg om du velger den ene eller den andre. MyISAM er tross alt default engine i MySQL og den er absolutt brukbar.

[DanOve]

for å si det sånn. jeg har ikke blitt noe spesielt klokere.

hehehe..

[siDDis]

Du kan ikkje sei at MyISAM er brukbar til skriving når den låser på tabellnivå.

MyISAM er faktisk ikkje brukandes til noko som helst pågrunn av risikoen med dataintegriteten. Raske selecter for enkle spørringer har sin fordel, men med dagens minnepriser så ser eg ingen grunn til å bruke memcached/ehcache for ENDA raskere selecter.

 

Fleire nettsider som blant anna Facebook har hatt problemer med dataintegriteten til MyISAM og ytelsen til InnoDB og jobber nå delvis med Oracle. http://tbe.taleo.net/NA3/ats/careers/requi...s=1&rid=222

 

Skal man ha solid dataintegritet, høg ytelse på skriving/lesing, minst mogleg kompleksitet ved innstallasjon/oppsett og svært få samtidige brukere så bør ein kikke på SQLite. Og da er databasen bare ein fil og lett å flytte, kopiere osv...

SQLite fungerer fint opptil fleire TB, men som sagt, den sliter med mange samtidige brukere som skal skrive.

[blackbrrd]

Eneste fordelen til SQLite fremfor postgres/mysql med innodb er at databasen blir lagret som en fil... Skjønner ikke helt hvorfor du anbefaler den...

 

Hvis du skal flytte en database er det ikke verre enn at du tar en backup - så får du en fil du kan restore på en annen maskin...

[siDDis]

SQLite har mange fordeler over andre databaser. Den er jo superpopulær til heilt enkle ting fordi den er så enkel å bruke, rask og mykje lettare å ta backup av enn dei større databasene.

 

Nå er det jo ikkje direkte vanskeleg å bruke dei andre, men med SQLite så sparer ein mykje knoting. For ein som skal begynne med databaser så er SQLite den beste databasen å starte med fordi ein slipper den knotinga med å setja opp ein større database og finne ein leverandør som leverer ein database som er ACID. Alt ein trenger er PHP/Python der SQLite er innebygd.

[blackbrrd]

Iflg wikipedia så er ikke SQLite acid compliant, bl.a:

SQLite silently ignores referential integrity constraints (foreign key constraints), so does not satisfy a common consistency requirement.[citation needed]

 

Hvis du ikke har drevet med databaser før, så er det rimelig dumt hvis databasen ikke hjelper deg med referanseintegriteten. Det er fort gjort å glemme seg og få en ikke-konsistent database.

 

I tillegg så har SQLite denne "featuren"

...it is weakly typed ...

... one can insert a string into an integer column ...

Mao så kan man ved en feiltagelse legge inn en string inn i et heltallsfelt...

 

Det begynner å minne meg litt om visual basic i den forstand at det er enkelt for små programmer, men kompleksiteten øker fort jo større programmet blir. (fortere enn i f.eks c# eller java)

 

Referanse:

http://en.wikipedia.org/wiki/SQLite

[kaffenils]

...it is weakly typed ...

... one can insert a string into an integer column ...

Mao så kan man ved en feiltagelse legge inn en string inn i et heltallsfelt...

 

LOL

Høres ut som klassisk ASP og PHP. Hva er poenget med slike features?

Hvis trådstarter vil lære seg et "ekte" RDBMS (som er gratis og uten begrensinger) er det nok bare å hoppe rett på Postgresql. Admin GUIet er faktisk ganske greit å jobbe med.

[siDDis]

Det er sant at Foreign keys ikkje er skikkeleg støttet, dette løses med å lage triggers for å få tilsvarendes funksjonalitet. Det er litt rot i Wikipedia artikkelen, men den er ACID compliant som det også står i den artikkelen.

 

Og når det gjelder kvifor det er weakly typed så er forklaringa følgende hentet frå deiras faq

 

(3) SQLite lets me insert a string into a database column of type integer!

 

This is a feature, not a bug. SQLite does not enforce data type constraints. Any data can be inserted into any column. You can put arbitrary length strings into integer columns, floating point numbers in boolean columns, or dates in character columns. The datatype you assign to a column in the CREATE TABLE command does not restrict what data can be put into that column. Every column is able to hold an arbitrary length string. (There is one exception: Columns of type INTEGER PRIMARY KEY may only hold a 64-bit signed integer. An error will result if you try to put anything other than an integer into an INTEGER PRIMARY KEY column.)

 

But SQLite does use the declared type of a column as a hint that you prefer values in that format. So, for example, if a column is of type INTEGER and you try to insert a string into that column, SQLite will attempt to convert the string into an integer. If it can, it inserts the integer instead. If not, it inserts the string. This feature is sometimes call type affinity.

 

SQLite er ein fantastisk database, og utroleg mange store seriøse selskaper bruker denne databasen.

 

Det er ein fin artikkel på SQLite sin webside som forklarer kor SQLite er nyttig og kor den er ikkje nyttig. http://www.sqlite.org/whentouse.html

Endret 8. juli 2008 av siDDIs

[blackbrrd]

... dette løses med å lage triggers for å få tilsvarendes funksjonalitet. ...

 

Kan du skrive en slik trigger for dette eksempelet:

CREATE TABLE kunde (
kundeid serial primary key,
kundenavn text
);

CREATE TABLE oppdrag (
oppdragid serial primary key,
id_kundeid integer references kunde,
oppdragnavn text
);

 

Litt nysgjerrig på hvor mye arbeid det er...

[siDDis]

Vell, det blir jo noko meir arbeid, men det finnes skript som lager triggers automatisk basert på create statements

Ein online versjon er tilgjengelig her: http://www.rcs-comp.com/site/index.php/vie...igger_generator

[blackbrrd]

Så istedetfor å skrive en enkel CREATE TABLE med REFERENCES som jeg viste ovenfor må du kjøre noe lignende dette:

 

-- Drop Trigger
DROP TRIGGER fki_bar_fooId_foo_id;

-- Foreign Key Preventing insert
CREATE TRIGGER fki_bar_fooId_foo_id
BEFORE INSERT ON [bar]
FOR EACH ROW BEGIN SELECT RAISE(ROLLBACK, 'insert on table "bar" violates foreign key constraint "fki_bar_fooId_foo_id"')
 WHERE NEW.fooId IS NOT NULL AND (SELECT id FROM foo WHERE id = NEW.fooId) IS NULL;
END;

-- Drop Trigger
DROP TRIGGER fku_bar_fooId_foo_id;

-- Foreign key preventing update
CREATE TRIGGER fku_bar_fooId_foo_id
BEFORE UPDATE ON [bar]
FOR EACH ROW BEGIN SELECT RAISE(ROLLBACK, 'update on table "bar" violates foreign key constraint "fku_bar_fooId_foo_id"')
     WHERE NEW.fooId IS NOT NULL AND (SELECT id FROM foo WHERE id = NEW.fooId) IS NULL;
END;

-- Drop Trigger
DROP TRIGGER fkd_bar_fooId_foo_id;

-- Foreign key preventing delete
CREATE TRIGGER fkd_bar_fooId_foo_id
BEFORE DELETE ON foo
FOR EACH ROW BEGIN SELECT RAISE(ROLLBACK, 'delete on table "foo" violates foreign key constraint "fkd_bar_fooId_foo_id"')
 WHERE (SELECT fooId FROM bar WHERE fooId = OLD.id) IS NOT NULL;
END;

-- Drop Trigger
DROP TRIGGER fki_bar_fooId2_foo_id;

-- Foreign Key Preventing insert
CREATE TRIGGER fki_bar_fooId2_foo_id
BEFORE INSERT ON [bar]
FOR EACH ROW BEGIN SELECT RAISE(ROLLBACK, 'insert on table "bar" violates foreign key constraint "fki_bar_fooId2_foo_id"')
 WHERE (SELECT id FROM foo WHERE id = NEW.fooId2) IS NULL;
END;

-- Drop Trigger
DROP TRIGGER fku_bar_fooId2_foo_id;

-- Foreign key preventing update
CREATE TRIGGER fku_bar_fooId2_foo_id
BEFORE UPDATE ON [bar]
FOR EACH ROW BEGIN SELECT RAISE(ROLLBACK, 'update on table "bar" violates foreign key constraint "fku_bar_fooId2_foo_id"')
     WHERE (SELECT id FROM foo WHERE id = NEW.fooId2) IS NULL;
END;

-- Drop Trigger
DROP TRIGGER fkdc_bar_fooId2_foo_id;

-- Cascading Delete
CREATE TRIGGER fkdc_bar_fooId2_foo_id
BEFORE DELETE ON foo
FOR EACH ROW BEGIN DELETE FROM bar WHERE bar.fooId2 = OLD.id;
END;

 

Istedet?

 

Tipper alle nybegynnere kommer til å få til det...

 

Eller kanskje de sliter litt..

[siDDis]

Vil påstå det er framleis enklare med å kopiere inn create table statements og klippe ut create trigger statements enn å innstallere/konfiguere/koble seg til ein av dei større.

 

Og ikkje minst finne ein host som leverer ein database som er ACID.

[kaffenils]

Det er ein fin artikkel på SQLite sin webside som forklarer kor SQLite er nyttig og kor den er ikkje nyttig. http://www.sqlite.org/whentouse.html

 

Må si jeg er veldig uenig i endel av "when to use" punktene. Som et embedded én-bruker system er det sikkert bra, men punktene:

 

1. Stand-in for an enterprise database during demos or testing

2. Database Pedagogy

3. Websites

 

...er jeg helt uenige i.

1. Det må by på masse problemer å porte et skikkelig RDBMS som Oracle, SQL Server, Posgresql eller DB2 til SQLite siden SQLite mangler elementære ting som foreign keys.

2. Hvordan kan det brukes i opplæring når det, som i pkt. 1, mangler såpass mye elementær funksjonalitet. Hadde de tenkt å vise at foreign keys skal løses med triggere?

3. Yeah right! Trenden i webverden viser at brukerinteraksjon (kommentarer, debatter etc) blir mer og mer vanlig. Hvordan har SQLite tenkt å klare dette når all skriving gjøres ved at hele database låses ekskusivt for den prosessen som skriver? For en gammeldags statisk webside så går det kanskje, men jeg ser ikke poenget med å bruke SQLite til dette heller når det finnes så mange gode alternativer.

[blackbrrd]

ACID compliant database = mindre vedlikehold

Ikke ACID compliant database = mer vedlikehold, tyngre å utvikle mot*

 

Nå skal det nevnes at å installere f.eks postgres på windows er gjort på ca 5 minutter og er ikke akkurat vanskelig...

 

Jeg er enig med deg at de færreste leverer gratis databasehosting som er ACID compliant.

 

Det er rimelig få som bruker f.eks prepared statements for å beskytte seg mot SQL-injection, men det er ikke lurt for det.

 

*Du må gjøre en rekke ting manuellt istedetfor automatisk, som f.eks med SQLite og foreign key constraints.

[siDDis]

Det er ein fin artikkel på SQLite sin webside som forklarer kor SQLite er nyttig og kor den er ikkje nyttig. http://www.sqlite.org/whentouse.html

 

Må si jeg er veldig uenig i endel av "when to use" punktene. Som et embedded én-bruker system er det sikkert bra, men punktene:

 

1. Stand-in for an enterprise database during demos or testing

2. Database Pedagogy

3. Websites

 

...er jeg helt uenige i.

1. Det må by på masse problemer å porte et skikkelig RDBMS som Oracle, SQL Server, Posgresql eller DB2 til SQLite siden SQLite mangler elementære ting som foreign keys.

2. Hvordan kan det brukes i opplæring når det, som i pkt. 1, mangler såpass mye elementær funksjonalitet. Hadde de tenkt å vise at foreign keys skal løses med triggere?

3. Yeah right! Trenden i webverden viser at brukerinteraksjon (kommentarer, debatter etc) blir mer og mer vanlig. Hvordan har SQLite tenkt å klare dette når all skriving gjøres ved at hele database låses ekskusivt for den prosessen som skriver? For en gammeldags statisk webside så går det kanskje, men jeg ser ikke poenget med å bruke SQLite til dette heller når det finnes så mange gode alternativer.

 

1. Den fungerer heilt fint til ein stand-in database til testing og demoer, men ikkje i alle absolutt alle tilfeller. Foreign keys blir jo parset, men ikkje brukt før du lager triggers.

 

2. SQLite kan brukes til opplæring til dei elementære tinga, akkurat det med foreign keys er jo litt dumt, men triggers, prosedyrer, transaksjoner er jo der. Pluss den støtter komplekse querier...ikkje akkurat right join eller full outer join. Bortsett frå mangelen til foreign keys constraints så er SQLite ypperleg til opplæring. Når ein er på eit meir avansert nivå så er det jo ein sjølvfølge å bruke ein av dei større databasene.

 

3. Trenden viser at enda så er 99% av nettstedene såpass små med mindre enn 100 000 treff til dagen. 10 innlegg i sekundet på eit nettsted er ikkje nok til at det skal bli treigt sjølv om heile fila blir låst.