104

Особенности национального проектирования БД

Ковыряли таблицы на работе на предмет того как заполняются анкеты клиентов, попалось на глаза интересное описание поля

Особенности национального проектирования БД Скриншот, Работа, База данных, Админ

Дубликаты не найдены

+13

1. bigint для guid не хватит

2. MobileOperator - нормализировать

3. Marital - на int8 перевести, если нет, то на smallint, т.к. практика показывает, что потом добавится "разведён", "вдова" и прочее

4. deleted заменить на state, тоже такого же типа, как в 8, и там уже статусы расписать: new, changed, syncronized, deleted, etc.

5. Сабжевый iscompleted также заменить на int и хранить там enum признаков: "конченый", "не платит вовремя", "много пиздИт", "много пИздит", etc

раскрыть ветку 10
+3

2. Зависит от назначения. Если эти данные используются только для отображения вместе с юзером и важна скорость выборки то незачем это делать.

4. Вполне возможно что запись может быть new и в тоже время удалена. Лучше таки этот флаг отдельно хранить.

5. isCompleted лучше переименовать в completed по аналогии с deleted

раскрыть ветку 1
0
2. Зависит от назначения. Если эти данные используются только для отображения вместе с юзером и важна скорость выборки то незачем это делать.

Даже если только для отображения - вытащить маленький список на клиент и им заполнять комбики


Вполне возможно что запись может быть new и в тоже время удалена

Если она и new и удалена, и оба два надо хранить - храни enum, нафиг лишние поля плодить?

-1

4. deleted заменить на state, тоже такого же типа, как в 8, и там уже статусы расписать: new, changed, syncronized, deleted, etc.

1. если syncronized - признак обмена, то какого лешего его хранить в том же поле, что и new, changed, deleted?

2. new, changed - нет смысла хранить, они вычисляются по полю типа дата/время последней модификации (lastchangedate).

так что deleted - там единственное поле без косяков (+lastchangedate)

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

Думаю разработчик БД из вас так-себе.

И DBA вправе набить морду "автору" этой таблички..

раскрыть ветку 7
+1
Наверное, вы никогда не работали с рпспределёнными системами, если вас 1 и 2 удивляют.
Также, поивсей видимости, вы понятия не имеете, в чём разница физической реализации между char и varchar в разных субд, иначе не несли бы ересь про большие.
Но вы не переживайте, мы все когда-то джунами были.
раскрыть ветку 6
+1

Конечно, база друга)))

раскрыть ветку 1
+1

Не, с этой базой фронтофис розницы работает. Софт писали не мы, но контора российская.

0

так то, важное поле

-2

и какой долбоклюй отводит под имя/фамилию/отчество/индекс по 255 символов????

БД не резиновая...

раскрыть ветку 1
0
А в чём проблема? Это же varchar, зависит от реализации субд.
А, это тот же джун, я там выше ответил уже
Похожие посты