v5.dk logo
Kom ind og besøg vores Discord Chat-community
Bliv medlem her eller læs mere om Discord her
1 stor kaffe i byen eller 1 hel md.
som Premium-medlem, valget er dit! :-)

Mere info Køb nu

Premium på v5.dk
v5.dk logo  v5.dk e-learning
Log på med Facebook
  • Log ind på v5.dk
  • Opret bruger
  • Log ind
  • v5.dk Premium
  • v5.dk Premium
  • Hvad siger vores kunder?
  • E-læring for begyndere
  • icon for WordPress 4 e-learning WordPress 4
  • icon for Office 365 e-learning Office 365
  • icon for Microsoft Word e-learning Microsoft Word
  • Bloggen for alle
  • E-læring for nørder
  • icon for PHP-programmering e-learning PHP-programmering
  • icon for iOS Programmering e-learning iOS Programmering
  • icon for Linux Server e-learning Linux Server
  • Bloggen for nørder
  • Arkiverede videoer
  • Fællesskab
  • Forum
  • Idéer og ønsker
  • Markedspladsen
  • v5.dk Premium
  • Gratis webhotel
  • Cloud-servere
  • Om v5.dk
  • Søg på v5.dk
  • Om v5.dk ApS
    • Om virksomheden
    • RSS-feeds og tjenester
    • Driftsmeddelelser
    • Presse-kit
    • Ledige jobs
    • Social Netværk
      • Facebook
      • Twitter
      • Instagram
    • Alt det andet
      • Forretningsbetingelser
      • Ophavsret og Copyright
  • Kontakt kundeservice
  • FAQ og Hjælp
    • Premium og abb.
    • Videoer og Afspiller
    • Forum og Points
    • Cloud-servers
  • Partner/Virksomhed
  • Partner-kanal
v5.dk logo mobile
  • Menu
  • Opret bruger

Mindst mulig belastning på MySQL

  • v5.dk
  • Forum
  • PHP-programmering
  • Mindst mulig belastning på MySQL
  • Sidevisninger: 3996 har set dette indlæg
Besvar #0Spørgsmål oprettet af @psto | 3665 points
5 points ude 8 indlæg 7 år siden Spørgsmålet er ikke løst
avatar
 

Hej du :-)

Jeg er igang med at flytte en større applikation med MEGET MySQL-data. Jeg er lidt i tvivl om det tynger databasen at have mange tabeller fremfor få med med flere rækker. Gør det nogen forskel? Pt. har hver bruger 24 tabeller som fyldes med en masse data. Dem havde jeg egentlig planer om at slå sammen og så indføre en kolonne der hed customer_id eller lignende. Det er dog et kæmpe arbejde og risikoen for at der opstår samkøringsfejl er høj.

 

Så spørgsmålet er vel egentlig - Gør antallet af tabeller i MySQL nogen forskel for performance?

 

avatar
 
Besvar#1 @dhh Admin kommenterede for 7 år siden

MySQL er i forvejen ikke den bedste ren performance mæssigt, jeg har hørt om der ude. (Det er dog noget tid siden jeg sidst har rodet med databaser.)

Hvad tager tid, er en query. Så kan du lave to queries (kald til databasen) om til en. Så har du allerede der en meget bedre performance. Og det er hvad det i sidste ende handler om. Og det er netop derfor at man tit opdeler en database i flere tabeller. Da man ikke har brug for at hente alle 24 tabeller hvis man kun vil hente en enkel række i en af dem.

Jeg håber at det gav lidt informationer. Det er det tætteste på noget svar jeg kan give, uden at vide hvad databasen faktisk indeholder. Og hvorfor du overhovedet har hele 24 tabeller.


Med venlige hilsner

Daniel H. Hemmingsen (@dhh)

avatar
 
Besvar#2 @jesperpetersen kommenterede for 7 år siden

Jeg er enig med @DHH,. Prøv evt at skrive hvad der er i de forskellig tabeller, så kan vi måske vejlede dig til god måde at gøre det på.

Det kommer også an på hvordan du bruger din database. Det kommer også an på hvor stort data-indhold du skal bruge de forskellig steder ved tabellerne mv.

Der er mange ting som spiller ind over.

avatar
 
Besvar#3 @db Admin kommenterede for 7 år siden

Hej @CBOX,

Umiddelbart lyder det ikke særligt effektivt at lave nye tabeller for hver bruger, jeg ville helt klart investere energi i at samle alle brugere og deres data i éen tabel som du også nævner. Det andet kan hurtigt blive noget kludder. Forestil dig du har 10.000 brugere, og du skal tilføje et nyt felt til Bruger-tabellen, så skal du ind og rette 10.000 tabeller versus 1.

Users
ID, Username, Email
1, Morten, [email protected]
2, Peter, [email protected]

Bookmarks
ID, UserID, URL
1, 1, google.dk
2, 1, bing.com
3, 2, v5.dk
4, 1, duckduckgo.com

I eksemplet over her har vi 2 brugere; Morten & Peter. Hver bruger har nogle bogmærker, Morten har bogmærket Google, Bing og DuckDuckGo - og Peter har bogmærket v5.dk.

Jeg håber dette svarede på dit spørgsmål, ellers må du endelig skrive igen, både jeg og de andre meget dygtige brugere herinde er klar til at hjælpe.


Med venlige hilsner

Daniel Bahls Signatur   Daniel Bahl (@db)
   CEO – v5.dk ApS

avatar
 
Besvar#4 @psto kommenterede for 7 år siden

Tak for jeres svar!

databasen indeholder personfølsomme data omkring kunder, fakturadata, lagerstyring, regnskabsdata m.m.  For at eliminere risikoen for at data blev blandet ved en fejl, eller risikoen for at forkerte data blev præsenteret for en forkert kunde, blev det nuværende setup udviklet således at hver bruger fik et antal tabeller. Antallet heraf er så vokset i takt med at systemet er videreudviklet, og det giver som @daniel også skriver noget administrativt bævl hvor jeg ofte er nødt til at programmere mig ud af at tilføje eller slette en kolonnenfor samtlige brugere. Alle tabeller refererer til hinanden på kryds og tværs og en sammenlægning af data er jeg mange for kan give rod i referencerne. 

Jeg opererer med flere typer af "kunder" ser er mine kunder omtalt som "brugere" samt deres kunder omtalt som "kunder"  

Eksempel (meget forsimplet)

Bruger1_kundekartotek

id, navn

1, Morten

2, Daniel

3, Maria

 

Bruger1_faktura

id, kunde_id, total

1, 1, 200.00

2, 3, 150.00

3, 1, 500.00

 

i dag er det jo nemt at at lokalisere Bruger1's data ved at vælge tabellerne startende med "Bruger1" og så forespørge på data herimellem  hvis vi gerne vil se liste over Mortens to fakturaer.

Skal jeg lægge data sammen i én tabel for alle brugere, dog stadig opdelt på kundekartotek og faktura så er jeg lidt nervøs for hvordan jeg får samlet data og får trukket krydsreferencerne på deres kunde_id med Rundt til alle tabeller? Det er jo blot ét eksempel  men derudover kærer en tabel med faktura_linjer som så ikke refererer til kunde_id men til faktura_id.

Det er helt sikkert - hvis jeg for år siden havde den viden jeg har i dag, havde jeg aldrig delt det sådan op i 24 tabeller pr. bruger. 

Jeg aner simpelthen ikke helt hvordan Søren jeg får migrerer data uden at det risikerer at gå galt

avatar
 
Besvar#5 @Kim kommenterede for 7 år siden

Du skal helt sikkert lave det om.

De grunde der er valgt som grundlag for at lave det sådan hænger sammen med manglende viden om det, da der ikke er noget til hindre for at sikre data ikke kan tilgåes af de andre.

Som udgangspunkt kan en god hovedregel være man skal følge de 3 første normalformer - selvfølgelig kan der være undtagelser.

Der er ingen problemer i at hente bruger 1's data selvom de ligger på den anden måde - det handler blot om din SQL forespørgsel som kan laves med JOIN og WHILE for at sikrer det er de korrekte data du får ud :)

avatar
 
Besvar#6 @psto kommenterede for 7 år siden

@Kim; den er jeg helt med på. Systemet er også vokset sig langt større end det var planen oprindeligt. Så du har ret. Det er bygget uden den viden der skulle til, og uden en plan for hvor projektet skulle havde. 

 

I forhold til "de 3 første normalformer", hvad tænker du der ?

avatar
 
Besvar#7 @aat kommenterede for 7 år siden

Enig med Daniel

Jeg kan sagtens forstå hvorfor man tænker indblanding, og selvfølgelig logisk set vil det være mere sikkert. Vil anbefale dig at kigge på multi-tenant database design, som jeg ser det er det et skråplan med single-tenant. Da vedligeholdelse af systemet hvis der kommer f.eks 5000 brugere ville kræve enormt meget tid, eller at du har scripts du laver til formålet at f.eks redigere tabeller :-)

Men et lille tip er at du har bestemte rettigheder pr. tenant i dit sytem til databasen, når du nu har et single-tenant databasen, det er en af de gode ting :-)


andreasaagaards Signatur

avatar
 
Besvar#8 @db Admin kommenterede for 7 år siden

 #4  Et præcist svar på en migrering af det hele er svær at løse over et forumindlæg, uden nærmere kendskab til data og struktur.

Men i bund og grund tænker jeg det nemmeste er at bygge nogle scripts der læser data ud af de mange tabeller, og samler dem i det nye database-design. Opsæt evt. et dev-miljø hvor du kan lege med en kopi af data, uden det påvirker driften, og så skal koden jo også omskrives lidt til at håndtere det nye database-design, hvilket også vil være en fordel at lege med i et dev-miljø.

Jeg tror det handler om at tage éen ting ad gangen, f.eks. alle brugere først, lave et script der læser dem ud i f.eks. en semikolum-sepereret fil - så du kører alle tabellerne igennem, og for hver tabel laver du en linje f.eks: username;password_hash;email.. 

Efterfølgende kan du på din dev-server lave et script som indlæser dataerne til den nye enkeltstående tabel, der håndtere brugerne, i det nye tabel-design.

Hvis du får brug for hjælp igennem denne process, er du velkommen til at oprette specifikke spørgsmål her i vores forum, så er vi klar til at hjælpe dig, med de problemer du måtte støde på.

Det er naturligvis blot éen måde at gøre det på, der er mange muligheder for at konvertere og arbejde med data, men jeg tænker at dette ville være den nemmeste- og mest overskuelige måde, så er man sikker på at man ikke "piller" ved data i drift-systemet, men blot ekspoterer, for så at lege med dem i et lukket dev-miljø.


Med venlige hilsner

Daniel Bahls Signatur   Daniel Bahl (@db)
   CEO – v5.dk ApS

avatar
 

Du er ikke logget ind

Du skal være logget ind på v5.dk før du kan benytte vores forum. Det er ganske gratis at oprette en bruger.

Opret en ny gratis bruger Log ind

Følger med i denne tråd

psto

Forum kategorier

  • Generelt
  • Guides & Howto114
  • Offtopic / Andet302
  • Microsoft Office
  • Microsoft Word15
  • Microsoft Excel4
  • Microsoft PowerPoint0
  • Web og hjemmesider
  • Wordpress17
  • Operativsystemer
  • Apple Mac OS X15
  • Apple iOS28
  • Microsoft Windows4
  • Linux16
  • Teknologier
  • Netværk og WiFi4
  • Internet-tjenester9
  • Programmering
  • PHP-programmering125
  • iPhone-/Xcode-programmering10

Aktive forum-tråde lige nu

cali weed bestellen
cali weed sorten
Hvor kan jeg finde lejeboliger i Danmark?
buy ielts certificate online, buy ielts certificate without exam
Korrekt ernæring
Buy valid ielts certificate online / buy Toefl certificate online
Vedr. netværk switch til coax router
Fejl ifm. var_dump
Bygget med af v5.dk
© Copyright 2006-2023 • Forretningsbetingelser • Copyright • Persondata- og Cookiepolitik
v5.dk ApS - Åbogade 15 - 8200 Aarhus N - CVR: 36902833
v5.dk logo
Hej, vi hedder v5.dk og vi laver e-learning på dansk

v5.dk er sat i verden for at gøre teknologi tilgængeligt og anvendeligt for både professionelle og almindelige brugere på alle niveauer.

93 200 555
  Skriv til os
v5.dk bruger cookies til at huske dine indstillinger, livechat samt til statistik
 

Alle vores priser er inkl. moms Sikker SSL-beskyttet forbindelse

Dankort og Visa-Dankort  Visa  Mastercard og Mastercard Junior  Maestro

  • Produkter
  • v5.dk Premium
  • Cloud-servers
  • v5.dk
  • Om v5.dk
  • Kunderne siger
  • Kontakt os
  • Presse
  • Stay updated
  • RSS & tjenester
  • Søg på v5.dk
  • Sitemap