Таблица пользователей
Таблица объявлений
Таблица транзакций
Есть 4 типа сделок
Мне не нравится проектировать таблицу транзакций таким образом, потому что есть столбцы, которые не требуются в соответствии со значением типа. Есть ли лучший способ спроектировать таблицу транзакций?
@P.Salmon У меня есть таблица уведомлений с 28 типами, и таблица уведомлений разработана так же, как таблица транзакций. Как вы думаете, дизайн моих таблиц хорош?
«Хорошо» по определению основано на мнении. Как мы должны оценивать «хорошо»? Каковы характеристики «хорошего» дизайна в вашем случае?
@NevilleKuyt Все работает хорошо на стороне клиента, но я спрашиваю здесь, потому что, возможно, есть лучший способ спроектировать таблицу, чем текущий способ, я ненавижу этот дизайн только потому, что в соответствии со значением типа будут использоваться некоторые столбцы, а некоторые не будет. Я думаю, что NoSQL решит эту проблему.






Это пример отображения отношений наследования («существует 4 типа транзакций») на модель реляционной базы данных. TL;DR: элегантных решений не существует — вам нужно выбрать ту неэлегантность, которую вы хотите. Есть 3 распространенных подхода.
Ваш дизайн является примером «наследования одной таблицы». С ним проще всего работать — другие варианты включают добавление таблиц в дизайн с необходимостью объединения — но для этого требуются столбцы, которые не всегда заполнены. Это также отправляет проверку объекта на прикладной уровень — вы не можете создать DDL, чтобы гарантировать, что AD_ID is not null для сущностей типа 1 и 2.
Вопрос, вероятно, привлечет ответы, основанные на мнении. Я предпочитаю хранить все транзакции в одном месте и жить с избыточностью.