2016-08-03 16 views
0

Ich erstelle eine Plattform, mit der Benutzer Seiten in einem AWS S3-Bucket speichern können. Die Seite wird so viele statische Informationen enthalten wie möglich, aber ich benötige immer noch die Seite, um eine Abfrage (AJAX) auszugeben, die meinen Server berührt. Diese Abfrage kann alle benötigten Informationen aus einer einzigen Tabelle mit einer Ausnahme, einem vollständigen Namen, abrufen. Um dies zu tun, brauche ich die Abfrage, um einer zweiten Tabelle beizutreten.Optimierung/Skalierung Anwendungsfall für eine SQL RDMS-Verknüpfung

Ich habe gelesen, dass Joins nicht serverintensiv sind, und dann einen anderen Artikel finden, der besagt, dass sie das sind. Wenn diese Abfragen häufig ausgeführt werden, sagen wir hunderttausende Male, sollte ich nur diesen vollständigen Namen in die ursprüngliche Tabelle aufnehmen, damit ich den Join nicht benötige? Wie viel Optimierung würde dies basierend auf der obigen Metrik ergeben?

MYSQL Schema -

TABLE: pet 
pet_key, int, pk 
pet_type_key, int 
pet_name, varchar 
color, varchar 
weight, decimal 
user_key 

TABLE: user 
user_key 
full_name 
email_address 
password 

konnte ich das Schema neu erstellen, damit ich einen Join nicht brauchen -

TABLE: pet 
pet_key, int, pk 
pet_type_key, int 
pet_name, varchar 
color, varchar 
weight, decimal 
user_key 
user_full_name, varchar // duplicate data, but faster to retrieve 

TABLE: user 
user_key 
full_name 
email_address 
password 
+0

Markieren Sie die verwendeten dbms. Zeigen Sie uns auch die zwei alternativen Tabellenentwürfe. – jarlh

+0

Was ist mit dem Passwort und der E-Mail-Adresse passiert? Hast du sie vergessen, oder hast du dich nicht richtig gefühlt, sie im Tiertisch zu verstauen ;-) – wildplasser

+0

Bleib beim aktuellen Design. – jarlh

Antwort

2

Als Ihr Kommentar schon sagt, Sie dies Grübeln.

Relationale Datenbanken wurden entwickelt, um Daten aus mehreren Tabellen zu kombinieren, und die meisten Datenbanken unterstützen eine Vielzahl von Join-Algorithmen, um dies zu erreichen.

In Ihrem Fall würden Sie eine Abfrage wie:

select * 
from pets p join 
    users u 
    using (user_key); 

Sie wollen sicher sein, dass Sie einen Index für users(user_key) haben. Normalerweise wird diese Spalte als Primärschlüssel deklariert, was einen Index für die Spalte garantiert.

Ihr vorgeschlagener Ansatz zum Duplizieren von Daten führt zu anderen Problemen. Vielleicht kann ein Benutzer seinen/ihren Namen im Laufe der Zeit ändern. Die pets Tabelle würde inkonsistente Namen haben. Ein anderes Problem ist der Speicher. Warum mehr Daten als nötig speichern?