Normalisatie versus Performace: voordeel/problemen van het verwijderen van linktabellen in (dit) schema?

Over het algemeen hou ik ervan mijn database zo schoon en uitbreidbaar mogelijk te houden.

Nadat ik echter enkele tests had uitgevoerd, besefte ik dat hoewel dit meestal de beste manier is om het te doen, het bij grote datasets een stuk langzamer gaat dan wat ik de "vuile" benadering van het probleem noem.

Laten we zeggen dat ik een tabel met objecten heb. Deze objecten zijn van bepaalde mensen. Eén object kan één persoon hebben, andere meer dan 1. Mijn eerste gedachte was zoals ik altijd doe, maak een objectentabel voor mijn objecten, een volkentabel voor mijn mensen en vervolgens een object_to_koplink-tabel.

Het koppelen van de object- en linker-tabel om alle objecten te krijgen waaraan een persoon is toegewezen, kan echter tot 3 seconden duren (dat is gebaseerd op ongeveer 400k records, maar slechts 1 link per object). Ja, ik heb ook de e.c.t.-index van de index ingesteld. om dingen te versnellen.

If I instead remove the people and linker table, and put the people in the objects table as columns and use 1/0 to set whether each person is assigned to that object, without joining the two large tables i see a speed of around 0.3 -> 0.7 seconds (varied greatly).

Om te beginnen hebben we slechts 2 mensen nodig. Maar ik wil niet te beperkend zijn als ik het kan helpen. Ik weet dat ik caching kan gebruiken en wat de eindgebruikerstiming niet kan verbeteren, maar is er een reden waarom dit als een heel slecht idee zou worden beschouwd om kolommen te gebruiken in plaats van tabellen te linken?

5
Indexen normaliseren en gebruiken.
toegevoegd de auteur Don Roby, de bron
Er is altijd een afweging bij het denormaliseren: reads (SELECT) kunnen versneld worden, maar schrijven (INSERT, UPDATE, DELETE) neigt te vertragen (omdat je over het algemeen meer beperkingen moet afdwingen). Of u denormaliseert, hangt gedeeltelijk af van de balans tussen leesbewerkingen en schrijfbewerkingen in uw toepassing. Jammer dat MySQL geen geïndexeerde views (a.k.a. gematerialiseerde views) ondersteunt.
toegevoegd de auteur Ted Hopp, de bron
Hier is goed te lezen over Normalisatie
toegevoegd de auteur Ibu, de bron
Normaliseren. De enige tijd om aparte "categorie" kolommen toe te voegen is als de lijst met "categorieën" goed begrepen en beperkt is. In jouw geval verwacht je dat de lijst met mensen groeit - je betaalt voor de beslissing om niet te normaliseren - ik beloof het :-)
toegevoegd de auteur drdwilcox, de bron
@pst. Dat is waar. Ik had indices moeten noemen.
toegevoegd de auteur drdwilcox, de bron
Invoegen is niet echt een probleem. De tabel "Mensen" zou zeer zelden worden bijgewerkt. Ik schat dat nadat de website live gaat. Er zouden in het komende jaar slechts 2 updates en invoegingen zijn. Wat de objectentabel betreft, die snel kan groeien om mee te beginnen, maar naarmate deze vult, zullen we minder snel gegevens invoeren. En alles behalve een SELECT is een administratief einde. Ik blijf misschien bij mijn gebruikelijke linker tafel en kijk wat er gebeurt. Ik denk dat het hele punt van een volledige oplossing is dat alles in die oplossing een rol speelt (caching e.c.t). Proost voor de antwoorden
toegevoegd de auteur Lee, de bron
Kleine foto's gaan ver in schema-gerelateerde vragen.
toegevoegd de auteur user166390, de bron
@drdwilcox Maar hiermee wordt het prestatieprobleem niet aangepakt - wat kan er worden gedaan om de genormaliseerde vorm te versnellen (of om sneller query's te maken, mogelijk met minder ACID-vereisten)?
toegevoegd de auteur user166390, de bron

4 antwoord

Ik heb een vergelijkbare opstelling.
Mijn join-tabel heeft 17.000.000 rijen. Mijn tabel 'persoon' heeft 8.400.000 rijen en mijn tabel 'objecten' heeft 300.000 rijen.

Ik heb query's met meerdere joins in mijn joins-tabel en unions van resultaten die tienduizenden rijen retourneren en die minder dan 1 seconde nodig hebben om te worden uitgevoerd (50-400 ms).

Ik denk dat je eerste lay-out goed zou kunnen zijn, maar je moet je waarschijnlijk concentreren op je indexen en query's.

2
toegevoegd

als het waar is dat een object tegelijkertijd bij meerdere personen kan horen ... houd dan de linktabel.

0
toegevoegd
wat betreft perofrmance - laat misschien wat uitleg zien voor de query ...
toegevoegd de auteur Randy, de bron

maar er is een reden waarom dit een heel slecht idee zou zijn   kolommen gebruiken in plaats van tabellen te linken?

Ik zou zeggen dat het een echt slecht idee is als je schaalbaarheid meer waardeert dan de prestaties die je hebt behaald.

Ik zou zeggen dat het een echt goed idee is als je de prestaties die je hebt behaald, meer dan de schaalbaarheid op prijs stelt.

0
toegevoegd

Ook in MySQL kan tabel wijzigen op enorme tabellen extreem lang uitvoeren, zodat het toevoegen van nieuwe gebruikers in een applicatie niet binnen een redelijke tijd mogelijk is.

0
toegevoegd