Два способа хранения одних и тех же данных

Question

На работе мы создаем форму, позволяющую агентам недвижимости отправлять свои новые разработки. Упрощенная версия нашей формы:

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

Add Another | Save 

Мы разрешаем агентам добавлять несколько строк. Однако в настоящий момент мы имеем абсолютно нулевой проверки дубликатов, на мой взгляд, позволяет нашей базы данных для хранения идентичные данные в два способами:

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

Очевидно, что строка может представлять собой как один единицы или Группа единиц.

Я утверждаю, что мы должны хранить разработки либо в одном направлении от другого, но, конечно, не оба. К сожалению, сторонние разработчики — Я в основном front-end — утверждают, что это неважно, и для меня это кажется абсурдным.

Для простого примера, сохранив его, как указано выше, а COUNT получить сколько события являются для продажи, которые имеют 3 спальни требует SELECT COUNT(*)и рассмотрения quantity поля.

Будучи разработчиком интерфейсов, в основном это логика представления, поскольку преобразование между их представлением как списком отдельных единиц или объединением их вместе должно быть задачей интерфейса/API, а бизнес-логика должна быть так или другой. В конечном итоге наша таблица, похоже, не нормализовалась вообще.

По моему скромному мнению, должен быть уникальный индекс на development_id, bedrooms.

Я прав в своих аргументах? Или ужасно неправильно?

Edit:

В разъяснении все это возможно в настоящее время, все из которых представляют собой один и тот же факт, и мой аргумент должен быть только один путь:

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

Same как:

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

То же, что:

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

Answer 1

Вы правы, должен быть только один способ записи каждого факта в базу данных и дублирование строк не должно быть разрешено. Если каждая строка представляет количество единиц, которые имеют определенное количество спален в определенной разработке, то уникальный ключ на development_id, bedrooms имеет смысл и предотвратит несколько записей для одного и того же устройства в каждой разработке.

Answer 2

Смешно, вы & Бэкэнд-коллеги/соперники оба справа.

Это неважно, на самом деле (в приведенных обстоятельствах). Хотя это действительно нарушает нормализацию БД (в указанных обстоятельствах).

Из того, что вы открываете, нет необходимости разбивать на несколько строк. Хотя представьте себе, что он получает еще один атрибут, который отныне отличает одну из трех кроватей от другой. Скажем, подходящий план. Или временную метку по любой причине. Это сразу начинает понимать.

Другое дело: чтение обычно не блокирует, пишет. Это означает, что на зрелой РСУБД с блокировками на уровне строк вставки (и чтение для COUNT) не будут конкурировать, а обновления счетчика будут.

Несмотря на то, что я не думаю, что ваши агенты по сбыту в совокупности достигнут даже одноразрядного TPS в своих дополнениях, вы можете рассмотреть проблему, которая не существует для масштаба. :-)