Wie wähle ich eine Tabelle aus einer anderen Tabellenspalte?

Ich habe einen Tisch für Plätze in einem Veranstaltungsort, aber es gibt mehrere Veranstaltungsorte. Ich könnte einen langen Tisch mit einer ID für jeden Veranstaltungsort neben jedem Sitzplatz erstellen, aber das könnte einen 2000 langen gemischten Tisch mit Veranstaltungsorten und Sitzplätzen ergeben. Also dachte ich, ich würde für jeden Veranstaltungsort einen Tisch mit eigenen Sitzplätzen schaffen. Wie zum Beispiel:Wie wähle ich eine Tabelle aus einer anderen Tabellenspalte?

tickets 

id | venue_name | seat_id 

venueA 

seat_id | section | row | seat_number

So würde Ich mag den Ort Tisch aus venue_name ("venueA") und der seat_id auszuwählen. Wie

SELECT seat_id from (select venue from tickets(venue_name));

Was ist für einen Ort der seat_id zu erfassen Ich versuche, ich weiß, so die Sektion, Reihen- und Sitz angefordert wird. Die Informationen zu Abschnitt, Reihe und Sitz sowie die Anzahl der Sitzplätze können für jeden Veranstaltungsort unterschiedlich sein.

Ich muss in der Lage sein, einen Sitz in VenueA zu identifizieren, während das getrennt von dem gleichen Sitz in VenueB bleiben.

Wenn das Sinn macht. Dies ist mein erster Ausflug in das Sql jenseits von einfachem Design und Schnittstellen zu anderen Menschen. Insbesondere verwende ich postgresql.

Quelle

2016-05-04 Rob

Können Sie Beispieldaten und erwartetes Ergebnis hinzufügen. –

Warum teilen Sie es nicht in Tabellen wie: Ort, Sitz, Ticket, Film und verwenden Sie dann grundlegende Fremdschlüssel - Primärschlüssel Beziehungen? Wie ticket sollte nicht einen Veranstaltungsort Namen, sondern eine Veranstaltungsort-ID (Fremdschlüssel) und der Name des Veranstaltungsortes sollte in der Veranstaltungsort-Tabelle sein –

Eine separate Tabelle für eine andere Klasse zu verwenden, die ansonsten wie eine bestehende ist, ist selten eine gute Idee. Fügen Sie einfach eine Spalte "venice_id" hinzu und machen Sie es fertig.Zwei oder mehr Tabellen in einer Datenbank mit identischer Struktur sind fast immer eine entartete De-Optimierung. – wallyk

Ich würde vorschlagen, ein Schema, das solche Tabellen wie Venue, Seat, Event und Ticket enthalten. Ich würde Ticket so modellieren, dass es eine EventId und SeatId hätte, ein Event würde eine VenueId enthalten, ein Sitz würde auch eine VenueId enthalten.

--- bearbeiten Erklärung um Tests zu schließen ---

Entschuldigt, wenn dies abwertend klingt, aber Sie können in postgre Erklären Sie verwenden, um die Leistung Ihrer Abfragen zu überprüfen und gegebenenfalls zu optimieren. Ich würde die DB mit Dummy-Daten laden, möglicherweise Indizes auf EventId und VenueId in Ihren untergeordneten Tabellen, um mit zu beginnen. Die Dokumentation für EXPLAIN ist hier http://www.postgresql.org/docs/8.1/static/sql-explain.html

Quelle

2016-05-04 16:36:11

Das ist genau was ich habe, aber ich war besorgt mit einem Tisch mit einer Mischung aus verschiedenen Veranstaltungsorten mit verschiedenen Sitzen. Dies kann ziemlich groß werden, da der VeranstaltungsortA Zeilen für Buchstaben beschriften kann, während der VeranstaltungsortB Nummern verwenden kann und dann jede eine andere Anzahl von Sitzen haben kann. Meine Sorge könnte mehr von meinem Mangel an Erfahrung dabei sein. – Rob

Es gibt kein Problem, viele Datensätze in einer Tabelle zu haben, Datenbanken sind dafür vorbereitet. Erstellen Sie einfach alle richtigen Indizes und Sie sind gut zu gehen. –

Mach dir keine Sorgen über große Zahlen, aber das ist, wo Datenbanken sind;) Wenn die Zahlen werden groß wie ein paar Millionen Tickets pro Tag, dann müssen Sie auf ein komplett anderes Design (Suche: nicht relationale Datenbank) –

Ihr Design ist schlecht gemacht, weshalb Sie auf dieses Problem stoßen. Anstelle von separaten Tischen für jeden Veranstaltungsort sollten Sie einfach einen Tisch mit Veranstaltungsorten haben. Der Sitztisch kann dann eine Veranstaltungsort-ID zusammen mit den Sitzinformationen haben. Etwas wie:

Veranstaltungsorte (venue_id, venue_name, etc.) Sitze (venue_id, seat_id, Abschnitt, Zeile seat_number) Tickets (venue_id, seat_id, ticket_id, etc.)

Statt "ticket_id" Für Tickets möchten Sie möglicherweise nur eine "event_id" haben, die sich auf Ihre Ereignisse bezieht und die jedes Ticket eindeutig identifizieren sollte, vorausgesetzt, dass Ihr System keine merkwürdigen Geschäftsanforderungen hat. Denken Sie auch über die Möglichkeit nicht reservierter Sitzplätze nach - ein Ticket gilt möglicherweise nicht für einen "Sitzplatz". Das würde auch die Architektur der Tabellen verändern.

Wenn Sie mehr von dieser Art von Datenbank-Design tun, dann sollten Sie auf jeden Fall Zeit nehmen, um Datenbank-Design und Normalisierung zu lesen. Es ist keine triviale Sache und die Auswirkungen eines schlechten (oder guten) Datenbankentwurfs sind riesige auf Software-Entwicklung.

Quelle

2016-05-04 16:40:25

Ich muss deine Idee durchlesen, aber es klingt nach dem, was ich bereits habe oder in der Nähe davon. Mein Problem könnte Mangel an Vertrauen und Erfahrung sein, die Zweifel verursachen. Ich habe studiert, was Sie vorgeschlagen haben. Ich musste es einfach all die Jahre selbst nicht machen. – Rob

Kleiner Kommentar, besser den Primärschlüssel der Tabelle "id" und nicht "tablename_id" nennen. So Seat (ID, Ort_ID, Abschnitt, Zeile, Sitznummer) –

@Hogan Was ich in meiner Frage zeige, ist was ich vorhatte zu tun; die Spielstätten in ihre eigenen Tische brechen. Ich habe das nicht in meinem ursprünglichen Design. – Rob

Wie wähle ich eine Tabelle aus einer anderen Tabellenspalte?

Antwort

Verwandte Themen