Kommentarer til: Database normalisering: Anden Normalform http://www.kim-andersen.dk/database_normalisering/mysql_anden_normalform_database.htm Webudvikling, Google, SEO, sociale medier mm. Fri, 30 Jul 2010 10:35:43 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Af: Normalisering af en database: Første Normalform http://www.kim-andersen.dk/database_normalisering/mysql_anden_normalform_database.htm/comment-page-1#comment-6834 Normalisering af en database: Første Normalform Mon, 04 Jan 2010 20:59:52 +0000 http://www.kim-andersen.dk/ikke-kategoriseret/normalisering_database_sql_2_normalform.htm#comment-6834 [...] Læs om 2. normalform her. [...] [...] Læs om 2. normalform her. [...]

]]> Af: Kim Andersen http://www.kim-andersen.dk/database_normalisering/mysql_anden_normalform_database.htm/comment-page-1#comment-2143 Kim Andersen Fri, 17 Oct 2008 09:48:42 +0000 http://www.kim-andersen.dk/ikke-kategoriseret/normalisering_database_sql_2_normalform.htm#comment-2143 Velkommen BlueBoden :) Det er nemlig en rigtig god ide at have en eller anden form for id til hver kolonne efter min mening, så man nemt kan få fat i hver enkelt række. Er også enig i dine andre betragtninger, tak for din kommentar :D Velkommen BlueBoden :)

Det er nemlig en rigtig god ide at have en eller anden form for id til hver kolonne efter min mening, så man nemt kan få fat i hver enkelt række.

Er også enig i dine andre betragtninger, tak for din kommentar :D

]]> Af: BlueBoden http://www.kim-andersen.dk/database_normalisering/mysql_anden_normalform_database.htm/comment-page-1#comment-2137 BlueBoden Fri, 17 Oct 2008 01:53:04 +0000 http://www.kim-andersen.dk/ikke-kategoriseret/normalisering_database_sql_2_normalform.htm#comment-2137 Så vidt at jeg har forstået, så er det vigtigt at have et unikt id som vi kan bruge i vores select statements, hvis bruger-id er et unikt nummer ville dette være en oplagt mulighed. Men i andre tilfælde har man ikke noget konkredt at gå efter, derfor ville det ofte være bedst at lave en id nøgle/kolonne, med et primært index og muligvis auto-increment. Det er også vigtigt vi har indexer på de nøgler vi bruger mest i vores selects. Eks i tilfældet med et biblotek ville det være en god ide at have et index på de mest relevante kolonner, "BogID" skulle helst være unikt, det samme med "lånerId" hvilket også helst skulle være unikt til den enkelte bruger, og begge bør have et primært index. Andre kolonner som. Eks "postnummer" ville jeg give et unikt index. Men det afhænger mere af den ønskede funktionalitet. Der er iøvrigt en anden fordel, som måske er vigtigere for større tabeller. Idet du opdeler en tabel, vil du også nedsætte antallet af concurrent-request på den enkelte tabel, det betyder at inserts, updates og andet kan blive udført hurtigere. Så vidt at jeg har forstået, så er det vigtigt at have et unikt id som vi kan bruge i vores select statements, hvis bruger-id er et unikt nummer ville dette være en oplagt mulighed.

Men i andre tilfælde har man ikke noget konkredt at gå efter, derfor ville det ofte være bedst at lave en id nøgle/kolonne, med et primært index og muligvis auto-increment.

Det er også vigtigt vi har indexer på de nøgler vi bruger mest i vores selects. Eks i tilfældet med et biblotek ville det være en god ide at have et index på de mest relevante kolonner, “BogID” skulle helst være unikt, det samme med “lånerId” hvilket også helst skulle være unikt til den enkelte bruger, og begge bør have et primært index.

Andre kolonner som. Eks “postnummer” ville jeg give et unikt index. Men det afhænger mere af den ønskede funktionalitet.

Der er iøvrigt en anden fordel, som måske er vigtigere for større tabeller. Idet du opdeler en tabel, vil du også nedsætte antallet af concurrent-request på den enkelte tabel, det betyder at inserts, updates og andet kan blive udført hurtigere.

]]>