Это должны быть 3 таблицы SQL или одна?

Question

Это новый вопрос, возникший из этого вопроса

Из-за ответов характер вопроса изменился, поэтому я думаю, что опубликовать новый вопрос можно (?).

Вы можете увидеть мой оригинальный дизайн БД ниже. У меня есть 3 таблицы, и теперь мне нужен запрос, чтобы получить все записи для конкретного пользователя для вычислений running_balances.

• Транзакции между пользователями, как взаимный кредит. Таким образом, единицы меняются между пользователями.
• Инвентаризация - это физическое вещество, занесенное в систему; пользователь получает единицы для этого.
• Потребления - это потребляемые физические вещи; за это пользователь должен заплатить единицы.

|--------------------------------------------------------------------------|
|  type     |  transactions       |  inventarizations  |  consumations     |
|--------------------------------------------------------------------------|
|  columns  |  date               |  date              |  date             |
|           |  creditor(FK user)  |  creditor(FK user) |                   |
|           |  debitor(FK user)   |                    |  debitor(FK user) |
|           |  service(FK service)|                    |                   |
|           |                     |  asset(FK asset)   |  asset(FK asset)  |
|           |  amount             |  amount            |  amount           |
|           |                     |                    |  price            |
|--------------------------------------------------------------------------|

(Обратите внимание, что «сумма» указана в разных единицах измерения; это записи и расчеты по этим суммам. За рамками объяснения почему, но это поля).

Вопрос заключается в следующем: «Может / должно ли это быть в одной таблице или быть несколькими таблицами (как у меня сейчас)?» Мне нравится решение с 3 таблицами, потому что оно имеет смысл с семантической точки зрения. Но тогда мне нужен такой сложный оператор выбора (с возможными отрицательными результатами производительности) для running_balances. Первоначальный вопрос в ссылке выше просил об этом утверждении, здесь я спрашиваю, подходит ли дизайн БД (извиняюсь, четыре двойных сообщения, надеюсь, что все в порядке).

Answer 1

Этот же вопрос возникает, когда вы пытаетесь внедрить систему Главной книги для единого учета. То, что вы назвали «транзакциями», соответствует «переводам», например, от сбережений к проверке. То, что вы назвали «инвентаризацией», соответствует «доходу», например, внесению зарплаты. То, что вы назвали «потреблением», соответствует «расходам», например, когда вы оплачиваете счет за электричество. Единственное отличие состоит в том, что в бухгалтерском учете все сводится к долларовой (или другой валюте) стоимости. Поэтому вам не нужно беспокоиться об идентификации активов, потому что один доллар так же хорош, как и другой.

Таким образом, возникает вопрос, нужно ли вам иметь отдельные столбцы для «суммы дебета» и «суммы кредита» или, альтернативно, можете ли вы просто иметь один столбец для «суммы» и ввести положительное число для дебетов и отрицательную сумму для кредитов. По сути, тот же вопрос возникает, если вы ведете двойную бухгалтерию, а не однократную.

С точки зрения внутренней арифметики и внутренней обработки данных все намного проще, если вы применяете подход с одним столбцом. Например, чтобы проверить, находится ли данная транзакция в балансе, все, что вам нужно сделать, это спросить, равна ли сумма (сумма) нулю.

Осложнения возникают, когда людям требуется традиционный вспомогательный формат для форм ввода данных, поиска на экране и опубликованных отчетов. Традиционный формат требует двух отдельных столбцов, помеченных «Дебет» и «Кредит», которые содержат только положительные числа или пробел, с ограничением на то, что у каждого элемента должна быть запись либо в дебете, либо в кредите, но не в обоих, а другой столбец должен быть не заполнено. Эти преобразования требуют определенного объема программирования между внешним форматом и внутренним форматом.

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

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

Answer 2

Вы сказали, что количество будет отличаться, тогда я думаю, что вы должны оставить каждый стол для себя.

Лично я ненавижу дизайн БД, в котором есть "другие правила" для заполнения таблицы в зависимости от типа объекта, который хранится в строке. Это просто становится грязно, и трудно удерживать ваши ограничения живо на таком столе.

Просто создайте индексированное представление, которое будет отвечать на ваши вопросы баланса, чтобы ваши запросы были «простыми»

Answer 3

На этот вопрос нет однозначного ответа, и ответы будут в основном сводиться к методологиям проектирования баз данных, принятым ответчиком.

Я бы посоветовал попробовать оба способа и найти лучший компромисс между запросами, производительностью и обслуживанием / удобством использования.

Вы всегда можете настроить представление, которое возвращает все 3 таблицы как одну таблицу для запросов и имеет поле type для типа процесса, к которому относится строка.