Zwei Möglichkeiten zum Speichern der gleichen Daten

Question

Bei der Arbeit erstellen wir ein Formular, um Immobilienmaklern zu ermöglichen, ihre neuen Entwicklungen einzureichen. Eine vereinfachte Version unseres Formulars lautet wie folgt:

Bedrooms: [Enter a number] 
Quantity: [Enter a number] 

Add Another | Save 

Wir ermöglichen Agenten, mehrere Zeilen hinzuzufügen. Aber im Moment haben wir absolut keine Validierung für Duplikate, die meiner Meinung nach unserer Datenbank in zwei Möglichkeiten zu speichern identische Daten ermöglicht:

| development_id | bedrooms | quantity | 
|----------------|----------|----------| 
| 1    | 3  | 1  | 
| 1    | 3  | 1  | 
| 1    | 3  | 3  | 

eindeutig eine Reihe sowohl ein Einheit darstellen könnte oder ein Gruppe von Einheiten.

Ich argumentiere, dass wir die Entwicklungen entweder eine Möglichkeit der anderen speichern sollten, aber sicherlich nicht beides. Leider sind die Back-End-Entwickler — Ich bin vor allem Front-End — argumentieren, dass es keine große Sache ist, und das scheint mir absurd.

Für ein einfaches Beispiel, indem er sie als den oben genannten, eine COUNT speichern, wie viele Entwicklungen zum Verkauf zu erhalten, die 3 Schlafzimmer haben erfordert eine SELECT COUNT(*)und Berücksichtigung des quantity Feld.

Als Front-End-Entwickler weitgehend zwischen wodurch sie als eine Liste von einzelnen Einheiten Präsentationslogik, zu sein scheint, oder die Gruppierung sie zusammen eine Front-End/API Aufgabe sein sollte, weil die Umwandlung und die Logik Geschäft sein sollte auf die eine oder andere Weise. Letztendlich scheint unsere Tabelle überhaupt nicht normalisiert zu sein.

In meiner bescheidenen Meinung sollte es einen eindeutigen Index auf development_id, bedrooms geben.

Bin ich richtig in meinem Argument? Oder schrecklich falsch?

Edit:

davon in Klärung aller zur Zeit möglich sind, die alle die gleiche Tatsache darstellen, und mein Argument ist, es sollte nur ein Weg:

| development_id | bedrooms | quantity | 
|----------------|----------|----------| 
| 1    | 3  | 1  | 
| 1    | 3  | 1  | 
| 1    | 3  | 1  | 

Same wie:

| development_id | bedrooms | quantity | 
|----------------|----------|----------| 
| 1    | 3  | 1  | 
| 1    | 3  | 2  | 

Gleiche wie:

Answer 1

Sie haben Recht, es sollte nur einen Weg geben, um jede Tatsache in einer Datenbank aufzuzeichnen und doppelte Zeilen sollten nicht erlaubt sein. Wenn jede Zeile die Anzahl der Einheiten mit einer bestimmten Anzahl von Schlafzimmern in einer bestimmten Entwicklung darstellt, ist ein eindeutiger Schlüssel auf development_id, bedrooms sinnvoll und verhindert mehrere Einträge für die gleiche Art von Einheit in jeder Entwicklung.

Answer 2

Lustig, Sie & Backend Kollegen/Konkurrenten sind beide richtig.

Es ist keine große Sache, für echte (in den gezeigten Umständen). Obwohl es wirklich DB-Normalisierung verletzt (in den gezeigten Umständen).

Von dem, was Sie aufdecken, müssen Sie nicht in mehrere Zeilen aufteilen. Obwohl man sich vorstellen kann, dass es von nun an ein anderes Attribut erhält, das sich von einem anderen unterscheidet. Sag, apt Plan. Oder ein Zeitstempel, aus welchem ​​Grund auch immer. Es beginnt sofort sinnvoll zu machen.

Eine andere Sache hier: liest sind in der Regel nicht blockierend, schreibt sind. Das bedeutet, dass bei einem ausgefeilten RDBMS mit Sperren auf Zeilenebene die Einfügungen (und die Lesevorgänge für COUNT) nicht konkurrieren, während Aktualisierungen für einen Zähler dies tun würden.

Obwohl ich weit davon entfernt bin zu denken, dass Ihre Immobilienmakler kombiniert würden jemals sogar einstellige TPS in ihren Zusätzen erreichen, so können Sie ein Problem nicht existent für eine Waage betrachten. :-)