Relations logik som stör mig.

[mindsleep]

Jag och Anjuna hade en liten diskussion för ett par dagar sedan ang. relations logik.

 

Mitt problem är låt oss säga att jag har 2 tabeller som ser ut ungefär så här:

[projektledare]

pid,fornamn,efternamn

 

[noteringar]

prid,notering,projektledareId

 

En projektledare har gjort en massa noteringar och nu bestämmer sig admin för att radera projektledaren för att han ska sluta. Om han då vill spara noteringarna som projektledaren gjort så blir det ett litet dilemma. Eftersom noteringar.projektledareId pekar mot en tom post.

 

Jag och Anjuna diskuterade detta. Mitt förslag var att utöka "noteringar" med ytterligare ett fält (projektledarnamn) så är det problemet löst. Vid en borttagning av en projektledare så uppdateras noteringar.projektledareId=-1 och projektledarnamn=projektledare.fornamn+projektledare.efternamn

 

Anjuna gillade inte att jag förstörde databas designen på det viset hans förslag är att flytta allt till en tabell historik. Jag föll för den idén.

 

Men samtidigt så vill jag ändå behålla noteringar i tabellen [noteringar]. En notering är en notering oavsett när den inträffade.

 

Nåväl. Laddade hem phpBB och undersökter hur dom gjort. De har anammat "min" metod. Det vill säga 2 fält i post tabellen som innehåller dels användarnamn och dels användar id. När en användare raderas så raderas användaren i tabellen user. Samtidigt sätts användarnamnet som text i tabellen posts och användarId till en Anonym post som finns i user tabellen...varför de gör så vet jag inte och inte bara sätter -1 vet jag inte. Men det har säkert sin anledning någon annanstans i koden.

 

Vad tycker ni andra om detta? Kanske bara jag som har fel-tänk.

 

//MVH Mindsleep

 

I am who i am, you are who you are, i respect that

 

 

Tråden flyttad från Databaser - övriga av moderator

 

[inlägget ändrat 2008-05-14 18:48:21 av Cluster]

[lizardKng]

Vad sägs om

 

[projektledare]

pid,fornamn,efternamn

 

[noteringar]

nid,notering

 

[???]

pid,nid

 

På så vis är och förblir alla noteringar desamma för alltid. De som kan knytas till en viss projektledare kan göras så. Försvinner projektledaren påverkas inte noteringen.

 

varför de gör så vet jag inte och inte bara sätter -1 vet jag inte. Men det har säkert sin anledning någon annanstans i koden.

 

Om en notering alltid ska relatera till en projektledare ska den väl göra det?

 

[mindsleep]

Vad sägs om

 

[projektledare]

pid,fornamn,efternamn

 

[noteringar]

nid,notering

 

[???]

pid,nid

 

Nej. Om du skriver ut en en notering så vill du ju hämta ut namnet på den som skrivit noteringen.

 

Typ som phpBB har gjort tror jag är bästa lösningen...eller så kanske jag har fel. Tankeprocessen har varit ganska långsam den här veckan.

 

Projektledaren ska helt raderas. Men samtidigt ska han noteringar finnas kvar. Går säkert att lösa med hjälp av att skapa ett fler relationstabeller eller dyl. Men tycker ändå phpBB lösningen är smidigaste. I alla fall verkar dom hålla med om det.

 

//MVH Mindsleep

 

I am who i am, you are who you are, i respect that

 

[inlägget ändrat 2007-08-24 23:50:17 av mindsleep]

[mindsleep]

Vi ändrar exemplet. Det KAN ju hända att man vill spara projektledar historik också.

 

Låt oss ta ett forum exempel alá phpBB.

 

[user]

user_id,username,user_password

 

notering: innehåller en massa skräp som födelsedag, avatar och annat.

 

[posts]

post_id,poster_id,post_username(text)

 

notering: uppenbar relation mellan posts.poster_id=user.user_id

 

Om man nu vill ta bort användaren men spara hans postningar så sätts posts.poster_id=1 (dummy post i user tabellen). Sedan säts posts.post_username=user.username. Sist men inte minst raderas han helt och hållet från user tabellen.

 

Det känns som en otroligt bra lösning. Även om det anses som dålig databasdesign. Men jag håller inte riktigt med.

 

//MVH Mindsleep

 

I am who i am, you are who you are, i respect that

 

[lizardKng]

Nej. Om du skriver ut en en notering så vill du ju hämta ut namnet på den som skrivit noteringen.

 

Det ges ju av min lilla extratabell. Nåja, kanske inte helt lyckat ändå.

 

Om man tänker i ett större perspektiv tycker jag det känns bakvänt att "smutsa ner" t ex noteringar med det som redan finns på annat ställe.

 

Nu är det iofs bara noteringar så exemplet är ju lite "litet". Tänk om det finns an massa andra saker som relaterar till projektledare, blir det inte stökigt då om viss information om projektledare finns på (potentiellt sett) många andra ställen?

 

Nu ska det erkännas att jag inte jobbar med databaser men principen blir densamma med datastrukturer i vanlig programmering.

 

Eller kanske man ska knyta noteringar till en mer anonym sak som "person" och låta dessa finnas kvar? Att de råkar vara projektledare under en tid kan modelleras separat?

 

 

 

[Anjuna Moon]

Jag vidhåller som jag ursprungligen gjorde att så länge man vill behålla något relaterat till huvudtabellen (i detta fall projektledaren) så skall denna post inte raderas. Om personen slutar så är det inte svårare än att man i tabellen för projektledare har ett fält Status [prospekt|anställd|vikarie|avslutad].

 

 

Även om det anses som dålig databasdesign. Men jag håller inte riktigt med.

Man kan ju tycka vad man vill, men eftersom jag studerat väldigt mycket databasdesign (och dessutom utvecklat databaser i över 11 år) så anser jag mig nog rätt på det klara med hur en bra databasdesign ser ut.

 

Kom även ihåg att bara för att en anställd slutar på ett företag så bör deras uppgifter inte raderas ur databasen. Det finns många anledningar att behålla dessa data. Så länge det inte var en felinlagd anställd så skall den stanna kvar i db:n.

 

Men allt har ju med användningsfallet att göra. Handlar det om något så trivialt som en inläggs-databas så kvittar det väl kanske.

 

 

[mindsleep]

men eftersom jag studerat väldigt mycket databasdesign (och dessutom utvecklat databaser i över 11 år) så anser jag mig nog rätt på det klara med hur en bra databasdesign ser ut.

 

Det är därför jag ber om andra perspektiv. Jag har inte hållit på med databaser i så många år.

 

Men både er har tagit mitt exempel på projekt...ta istället Forum exemplet som jag postade efter en stund.

 

Det finns ingen anledning som helst att spara en user efter att den sagt upp sitt konto eller blivit kickad av admin. Som jag sa...det kan finnas anledning att spara projektledar historik. Men inte som en user.

 

Ta forum exemplet istället. Det är bättre.

 

The bottom line är att jag stör mig på "god databasdesign" då det inte finns någon uppenbar funktion och att en annan lösning kan vara bättre men anses som "dålig databasdesign".

 

Som sagt, all respekt för dina åsikter Anjuna. Både du och Lizard är på en annan nivå än vad jag är. Det kan jag garantera att phpBB killarna är också. De valde "dålig databasdesign".

 

Fortsätt gärna diskussionen. Kanske Mr Andersson kan komma in med lite synpunkter också.

 

//MVH Mindsleep

 

I am who i am, you are who you are, i respect that

 

[mindsleep]

Det ges ju av min lilla extratabell. Nåja, kanske inte helt lyckat ändå.

 

Så länge projektledaren finns så fungerar relationen. Men då projektledare tas bort blir det en "korrupt" databas.

 

Om man tänker i ett större perspektiv tycker jag det känns bakvänt att "smutsa ner" t ex noteringar med det som redan finns på annat ställe.

 

Min fråga är om det är bättre att smutsa ner med ett extra fält eller en extra tabell...eller extra fält med flaggor+ursprungsfälten.

 

Min tes är att det inte är bättre. Ett extra fält som innehåller samma informations som finns i en relaterad tabell är bättre. phpBB har gjort så. Men så länge usern existerar är fältet username i tabellen posts tomt. Så det är inte EXAKT så att samma info finns i 2 tabeller samtidigt

 

Som sagt. Forum exemplet är bättre att diskutera över. En projektledare kan man vilja ha kvar även om han slutat. Men inte en user i ett forum. Det finns ingen anledning till det.

 

//MVH Mindsleep

 

I am who i am, you are who you are, i respect that

 

[lizardKng]

Så länge projektledaren finns så fungerar relationen. Men då projektledare tas bort blir det en "korrupt" databas.

 

Vad menar du med korrupt?

 

Både projektledare och noteringar ska väl kunna finnas oberoende av varandra?

 

[zerblat]

Den här situationen är väl inte helt ovanlig -- att man vill kunna ta bort rader men ha kvar data som refererar till den. Jag har alltid löst det på samma sätt som Phenomen föreslår: Ha en kolumn som indikerar om raden är borttagen.

 

Nackdelen är förstås att du då måste ha kvar en massa data som inte längre behövs (förutsatt att du aldrig kommer behöva något annat än namnet på borttagna användare). Det kan ju hända att du senare kommer på att du skulle kunna ha användning av lite fler av användarkolumnerna.

 

Iaf, om det är mycket data det handlar om, så kan du spara det utrymmet genom att separera de kolumner som bara aktiva användare har, i en separat tabell:

[user]
id,firstname,lastname

[active_user]
id,email,cv,favourite_colour

 

En borttagen användare är alltså en användare som finns i user, men inte i active_user. Om du kör en inner join (t ex ... WHERE user.id = active_user.id), så får du automatiskt bara med de aktiva användarna.

 

Lösningen som phpBB använder är en fullösning. Det kan vara så att just i deras fall, så är det den bästa (eller minst dåliga) lösningen (t ex pga prestanda eller några egenheter i deras datamodell eller nåt annat), men jag tycker inte att du ska ta efter dem utan att veta varför de valde just den lösningen. Det kan helt enkelt va lathet eller okunnighet.

 

Man ska inte tro att bara för att ett projekt är framgångsrikt så är deras tekniska lösning överlägen. Ofta är det faktiskt tvärtom. Framgångsrika projekt innehåller en massa kompromisser, fulhack, och designmissar, medan de som hela tiden ser till att undvika sånt får mycket svårare att komma nånvart. Men det betyder absolut inte att man blir framgångsrik bara för att man har en massa fulhack. Det viktiga är snarare att vara pragmatisk och kunna acceptera en mindre vacker lösning när den vackra lösningen är för osmidig. Men man ska ändå sträva efter att få det så rent som möjligt.

 

[mindsleep]

Vad menar du med korrupt?

 

Både projektledare och noteringar ska väl kunna finnas oberoende av varandra?

 

Ja, men vem som skrivit noteringen måste komma fram vid visning av noteringen.

 

Ta Forum förslaget istället, det är ett bättre exempel på vad jag menar. Om en användare tas bort vad händer om man då vill ha kvar hans postingar? Namnet ska ju skrivas ut vid visning av en post.

 

"Korrupt" menade jag med att ett ID visas istället för namn.

 

//MVH Mindsleep

 

I am who i am, you are who you are, i respect that

 

[mindsleep]

Gör så att du inaktiverar kontot för projektledaren istället för att du tar bort det.

 

projektledare]

pid,fornamn,efternamn, aktiv

 

Det är också en lösning. Men vet inte om jag tycker den är speciellt bra.

 

//MVH Mindsleep

 

I am who i am, you are who you are, i respect that

 

[mindsleep]

Det viktiga är snarare att vara pragmatisk och kunna acceptera en mindre vacker lösning när den vackra lösningen är för osmidig. Men man ska ändå sträva efter att få det så rent som möjligt.

 

hmmm...gäller det även att spara data i databas. Som sagt, det blir ju lite skräpdata kvar i databasen.

 

//MVH Mindsleep

 

I am who i am, you are who you are, i respect that

 

[inlägget ändrat 2007-08-30 13:45:10 av mindsleep]

[lizardKng]

Ja, men vem som skrivit noteringen måste komma fram vid visning av noteringen.

 

Varför då? Det är väl inget som har med databasen att göra, det har väl med användaren av databsen att göra?

 

"Korrupt" menade jag med att ett ID visas istället för namn.

 

Då är det väl en "bugg" i koden som använder databasen?

 

 

Även i databasernas land måste det väl få finnas 0..flera-relationer? Om det inte kan finnas en notering utan tillhörande projektledare kan det inte heller få finnas en projektledare utan tillhörande notering.

 

Om användaren av databasen inte kan hitta vem som skrivit noteringen kan man ju skriva ut det?

 

[Anjuna Moon]

Även i databasernas land måste det väl få finnas 0..flera-relationer?

I det här fallet handlar det ju om en 1-M-relation och till M räknas även 0 (En användare kan ha 0+ antal inlägg, men ett inlägg tillhör en och endast en användare).

(Det du nämner skulle isåfall innebära en N-M-relation med specialfallet N=0, vilket då även skulle kräva att ett inlägg kan tillhöra 0, 1 eller flera användare. Så är inte fallet)

 

Förvisso kan man ju utelämna foreign key constraints i relationen men då har vi ju helt tappat just relationen mellan tabellerna. Då har vi en databas där relationsintegriteten helt och hållet styrs av klienten och det är därför jag vänder mig mot detta.

 

Jämför med exempelvis validering av användarinput på klient- (ex. Javascript) vs. serversidan (ex. PHP), eller validering i ett GUI-lager vs validering i mellanliggande businesslager. Skulle ni på fullt allvar våga utelämna server/businesslayer-valideringen? Svaret är förhoppningsvis nej så då ställer jag frågan varför ni accepterar denna svaghet i er databasdesign?

 

[mindsleep]

Skulle ni på fullt allvar våga utelämna server/businesslayer-valideringen? Svaret är förhoppningsvis nej så då ställer jag frågan varför ni accepterar denna svaghet i er databasdesign?

 

Vad menar du då du säger server/businesslayer-validering och GUI-validering?

 

Klient validering (javascript "checkar") och server validering (PHP "checkar") är självklara. Menar du validering av den data som exempelvis man får tillbaka eller den data som inte kommer fram ett fel). Så är det en självklarhet.

 

//MVH Mindsleep

 

I am who i am, you are who you are, i respect that

 

[lizardKng]

Min variant (som var tt medvetet avtsteg från ursprungsproblemet) var just M:N även om det kanske inte framgick så tydligt.

 

I det fallet borde både 0:N och M:0 vara tillåtna?

 

Nå, vi kanske modellerar olika verkligheter.

 

Förvisso kan man ju utelämna foreign key constraints i relationen men då har vi ju helt tappat just relationen mellan tabellerna. Då har vi en databas där relationsintegriteten helt och hållet styrs av klienten och det är därför jag vänder mig mot detta.

 

Nu förstår jag inte riktigt, menar du att klienten (vad menar du med klient?) ska ha obegränsad access till databasen? Det låter farligt? Eller kanske jag inte förstår vad som menas med en klient i sammanhanget?

 

[Anjuna Moon]

Klient validering (javascript "checkar") och server validering (PHP "checkar") är självklara. Menar du validering av den data som exempelvis man får tillbaka eller den data som inte kommer fram ett fel). Så är det en självklarhet.

 

Jepp, det var det jag menade. På samma sätt anser jag att en strikt constraint-policy i databasdesign är lika viktig (om inte viktigare, eftersom en och samma databas potentiellt kan ha så väldigt många fler typer av klienter kopplade till sig än ex. en serverscript-sida).

 

Nu är ju detta iofs en diskussion på lite högre nivå, eller snarare gällande större system där du inte får förutsätta vilken miljö databasen kommer användas i.

Idag kanske det är en webbsajt som nyttjar den, imorgon kanske det skall läggas till en web service som skall utnyttja datan och nästa år kanske det skall kopplas till ett internt affärssystem. Vidare kanske den som skapat den ursprungliga databasen inte finns kvar och inte lämnat efter sig någon dokumentation. Har du då inte definierat upp ex. foreign-key-constraints i databasen utan bara låtit den ursprungliga klientapplikationen styra vad som är relaterat till vad, ja då blir det inte lätt att reda ut relationerna i databasen.

 

Dessa scenarier är också en mycket stark anledning till att man aldrig skall skriva SQL-querys utanför databasen, utan hålla sig till anrop av stored procedures, speciellt om du använder väldigt mycket icke-standardiserad SQL. Annars blir det ett rent helvete att migrera till andra databasplattformar om så en dag skall ske.

 

Vidare ser ju denna constraint till att det inte går att radera en post i den refererade tabellen så länge det finns kvar poster i andra refererande tabeller som pekar dit, vilket ju faktiskt är en stor del av idén i en relationsdatabas. Annars har du ju bara en massa lösa entiteter som potentiellt hör ihop med varandra på något löst, fluffigt, imaginerat sätt styrt av något som ligger utanför databasen.

 

[Anjuna Moon]

M:N även om det kanske inte framgick så tydligt.

 

I det fallet borde både 0:N och M:0 vara tillåtna?

Ja, det stämmer.

 

Nu förstår jag inte riktigt, menar du att klienten (vad menar du med klient?) ska ha obegränsad access till databasen?

Va? Nä, jag förklarar med ett exempel istället:

 

- Säg att du har två tabeller, Tabell1 och Tabell2, där Tabell2 i din ER-design är relaterad via N-1 till Tabell1.

 

- Säg vidare att du skiter i att lägga in en FK i Tabell2 som pekar på PK i Tabell1, utan bara håller denna relation "i huvudet".

 

- I din klient sedan, ex. en webbsida, så lägger du till en post i vardera tabell som hör ihop med två st. på varandra följande Inserts. Snyggt, nu har du en post i Tabell2 som pekar på en post i Tabell1, allt väl så långt.

 

- Du har även en raderingsfunktion på webbsidan för att radera ur Tabell1. För att behålla relationsintegriteten och undvika felmeddelanden så ser du till att i klienten först radera relaterade poster i Tabell2. Allt väl även så här långt.

 

- Nästa år utvecklar någon annan en klient som ett Windowssystem i .Net. Denna utvecklare känner inte till att Tabell2 är relaterad till Tabell1 (det finns ju inte angivet någonstans alls i databasen och den gamla utvecklaren lämnade inte efter sig något ER-schema).

 

- Det nya systemet får också en raderingsfunktion som raderar ur Tabell1. Eftersom det saknas constraints går detta utmärkt (med constraints hade utvecklaren blivit varse relationen tack vare uppfångning av felmeddelandet som därefter skickas) och plötsligt hade det svävat omkring en massa faderslösa poster i Tabell2 som ingen har en aning om varför de är där.

 

Så det jag menade var att det var klienten som i praktiken upprätthöll relationsintegriteten medans databasen själv inte hade någon koll alls och tillät att denna bröts. Är jag tydlig nog i vad jag syftar på?

 

EDIT: Måste sova i vilket fall nu. Har just fått ett EPiServer-projekt som skall vara klart till nästa fredag och måste således lära mig programmera mot EPiServer imorgon bitti (ibland vore det skönt att ha ett stressfriare yrke, som ex. flygtrafikledare

[inlägget ändrat 2007-08-30 21:50:30 av Anjuna Moon]

[lizardKng]

Är jag tydlig nog i vad jag syftar på?

 

Med all önskvärd tydlighet

 

Det var väl det jag mistänkte men jag tyckte det verkade lite märkligt därav frågan.

 

I min värld brukar man alltid kapsla in viktiga funktioner i ett API som klienten använder. I implementationen av detta API ser man då se till att upprätthålla databasens integritet. På så vis får man skriva hur många klienter som helst, det spelar ingen roll eftersom de måste gå via detta API.

 

Går man däremot direkt mot databasen, ja, då blir det uppenbarligen farligt.

 

Jag trodde faktiskt inte man gjorde så i annat än små personliga hobbyprojekt.

 

Om du har tid får du gärna förklara vad ER-design, FK och PK är. Har aldrig hört begreppen förut (vi jobbar ju i helt olika domäner).

 

Fotnot: Vi använder en objektorienterad databas. Där finns varken SQL eller stored procedures. Däremot kan man förse alla databasklasser med metoder, precis som i objektorienterad programmering.

 

[inlägget ändrat 2007-08-31 08:18:11 av lizardKng]

[Mr Andersson]

I min värld brukar man alltid kapsla in viktiga funktioner i ett API som klienten använder. I implementationen av detta API ser man då se till att upprätthålla databasens integritet

 

I min värld låter det där farligt, speciellt för att det är alldeles för specifikt för en viss plattform. Vill man skapa en klient i tex PHP, så är det bara att banka om all kod, som egentligen redan skulle funnits i databasen.

 

Klienten ska i princip enbart syssla med sånt som har med användandet att göra, inte göra detaljfrågor till databasen.

 

 

[Anjuna Moon]

I min värld brukar man alltid kapsla in viktiga funktioner i ett API som klienten använder. I implementationen av detta API ser man då se till att upprätthålla databasens integritet.

Jo, detta är ett vettigt sätt att göra det på, dvs. att skapa ett datalager mellan databas och affärslogik och andra lager. Det är även det sätt jag jobbar på, men det är sällan ett sätt webbutvecklare som sitter med gamla miljöer som PHP och ASP nyttjar och därför tyckte jag det var viktigt att framföra vikten av en korrekt databasdesign.

 

Jag trodde faktiskt inte man gjorde så i annat än små personliga hobbyprojekt.

Tro mig, i webbutvecklingsbranschen är det mer standard än inte.

 

Om du har tid får du gärna förklara vad ER-design, FK och PK är. Har aldrig hört begreppen förut (vi jobbar ju i helt olika domäner).

FK=Foreign key, dvs det/de fält i en relaterad tabell som kopplas mot huvudtabellens PK=Primary key. En tabell skall alltid ha en PK, eller primärnyckel, men en FK använder du som sagt i relationer. Finns en FK så krävs det att det i huvudtabellen finns exakt en post vars PK motsvarar en eller flera poster med samma FK. Dvs. det får inte finnas värden i Tabell2.FK som inte existerar i Tabell1.PK.

 

ER är bara en av flera modeller för att beskriva just relationer mellan objekt. Du har säkert arbetat i andra. Du kan läsa mer om det här, men när du går in på länken så ser du nog direkt vad det handlar om

http://en.wikipedia.org/wiki/Entity-relationship_model

 

i använder en objektorienterad databas.

Vad härligt! Jag har bara studerat dessa i databasteorikurserna på KTH (och på den tiden var det nog bara teori kring det hela, tror inte ens de existerade på "riktigt"). Vad heter den ni använder?

 

[lizardKng]

API:et ska naturligtvis vara knutet till databasen. I "vår"miljö ligger koden "i databsen" så att säga, kanske det blir samma effekt som "stored procedures", det vet jag inte.

 

Poängen var att den som kodar för klienten inte ska behöva bry sig om hur databasen råkar vara strukturerad.

 

Vill man skapa en klient i tex PHP

 

Då ska det naturligtvis finnas ett API skrivet för de som ska använda PHP.

 

Att det finns ett sådant API måste väl vara bättre än att man skriver direkta databasanrop?

 

Det var som sagt det som var poängen.

 

Vilket språk det är skrivet i kan väl variera antar jag. En SQL-databas kanske använder stored procedures, en objektorienterad databas har sina metoder, en tredje kanske har sitt eget sätt.

 

Huvudsaken var att gränssnittet mot databasen (som klientprogrammeraren använder) inte ska tillåta de exempel som Anjuna listade (som skulle förstöra databasens integritet).

 

Återigen, i vilken form detta API kommer beror, förstås, på vilken miljö det är frågan om.

 

[mindsleep]

Det mynnade ut i lite OT. Men det är en underbar OT tråd.

 

Anjuna. Tack för att du förklarar allt så detaljerat. Då jag frågat mina databasmodelerare på tidigare jobb har de i princip ryckt på axlarna och sagt något i stil med "För det ska vara så".

 

Jag är ingen databasexpert själv (som bevisat) men jag kan så jag klarar mig. Jag har stött på flertalet stora/medelstora projekt som har haft just "dålig" databasdesign.

 

Jag har själv aldrig haft någon större utbildning om modulerande eller lär mig någon modell. Ganska mycket självlärd inom just databasdesign eftersom det är inte mitt huvudsakliga arbete.

 

Nåväl. Kul diskussion, känner till constraints, PK,FK och dyl. Men måste säga att de applikationer jag jobbat i (1 klient, ofast php) så har det modelerats i "logiska nycklar". Det vill säga att det finns alltid en primär nyckel...men de främmande nycklarna finns endast i huvudet, ej definerade i databaser.

 

MyISAM som är standard tabell formatet i MySQL har inte så stora möjligheter till god databasdesign. Det har däremot InnoDB. Problemet är att InnoDB suger lite extra kraft av MySQL.

 

Citerat från MySQL´s dokumentation:

"Do keep in mind that these benefits come at the cost of additional overhead for the database server to perform the necessary checks. Additional checking by the server affects performance, which for some applications may be sufficiently undesirable as to be avoided if possible. (Some major commercial applications have coded the foreign key logic at the application level for this reason.)

 

MySQL gives database developers the choice of which approach to use. If you don't need foreign keys and want to avoid the overhead associated with enforcing referential integrity, you can choose another storage engine instead, such as MyISAM. (For example, the MyISAM storage engine offers very fast performance for applications that perform only INSERT and SELECT operations."

 

Ja, det finns uppenbarligen en poäng med korrekt databasdesign...att skapa de extra tabellerna och dyl. OM databasen ska användas i andra syften än av just den klienten.

 

Men då det handlar om mindre applikationer som inte ska utmynnas i stora applikationer med olika typer av klienter...API´n och dyl så ser jag "korrekt databasdesign" som något som absolut inte är nödvändigt i annat än just för att "så ska det bara vara" mentaliteten.

 

Fortsätt gärna snacket. Intressant diskussion.

 

//MVH Mindsleep

 

I am who i am, you are who you are, i respect that

 

[lizardKng]

Vad heter den ni använder?

 

Jag får nog göra dig lite besviken - den är en del av den klusterplatform vi använder och är konstruerad inom företaget och finns inte tillgänglig på annat sätt.

 

Den är distribuerad (förstås) och bor i primärminnet. Klasserna definieras i ett eget språk och sedan kan man generera kod i Java och C++.

 

Den har sitt ursprung i AXE-N som utvecklades av Ellemtel fram till mitten av 90-talet.

 

Det finns i alla fall en rätt ordentlig beskrivning publicerad:

 

http://www.ericsson.com/ericsson/corpinfo/publications/review/1999_03/86.shtml

 

Tro mig, i webbutvecklingsbranschen är det mer standard än inte.

 

Jag har ingen anledning att misstro dig. Låter som upplagt för problem och med det i tanke måste förstås databasuppbyggnaden ta hand om "allt", det förklarar en hel del.

 

ER är bara en av flera modeller för att beskriva just relationer mellan objekt. Du har säkert arbetat i andra.

 

Våra projekt bygger mer på protokoll av olika slag och datamodelleringen är rätt sparsam.

 

[inlägget ändrat 2007-08-31 16:04:30 av lizardKng]