Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Должна ли быть согласованность данных в базе "по умолчанию" / 14 сообщений из 14, страница 1 из 1
14.04.2014, 14:34
    #38614234
avec
avec
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Должна ли быть согласованность данных в базе "по умолчанию"
Коротко опишу ситуацию. Имеется некая база данных + пользовательский интерфейс по работе с некоей информацией. Функционал разработан по согласованному с бизнесом ТЗ.

База в части реализации этих требований представляет собой несколько таблиц - основная сущность (например, документ) и подчиненные "1 к N" сущности (история изменений по документу, созданные проводки по документу и т.п.).

По прошествии нескольких лет пришла мысль анализировать то что хранится в этих таблицах. Выяснилось, что в БД никаких ссылочных ограничений целостности не сделано, внешние ключи отсутствуют. В программе были реализованы только те ограничения, которые явно прописаны в ТЗ. Но например, имеются изменения по документу, а самого документа в системе нет (удален).

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

У меня волосы шевелятся от такого подхода, но не могу найти что возразить... Должна ли база быть в согласованном состоянии, с нормально прописанными хотя бы элементарными констрейнтами, внешними ключами, даже несмотря на то что в ТЗ такого ПРЯМОГО требования нет?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2014, 14:51
    #38614262
АнатоЛой
АнатоЛой
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Должна ли быть согласованность данных в базе "по умолчанию"
avec...
Функционал разработан по согласованному с бизнесом ТЗ.
...
По прошествии нескольких лет пришла мысль анализировать то что хранится в этих таблицах.
...


Посмотрите ещё раз:
Несколько лет назад были сформулированы требования.
Несколько лет система работала.
Сегодня вам в голову пришла мысль.
Кто несколько лет назад должен был отвечать за то, чтобы система смогла поддержать вашу сегодняшнюю мысль?
Те кто должен был отвечать - подписали ТЗ (с обеих сторон). У них же проблем нет? :)

avec...
У меня волосы шевелятся от такого подхода, но не могу найти что возразить...
...
Должна ли база быть в согласованном состоянии, с нормально прописанными хотя бы элементарными констрейнтами, внешними ключами, даже несмотря на то что в ТЗ такого ПРЯМОГО требования нет?
База никому ничего не должна.
Спроектирована она в меру понимания заказчика и квалификации разработчика.
И даже работает! (самый нглавный показатель )
Может быть, разработчики даже задавали вопрос - что делать с удалёнными документами? Сохранившаяся история редактирования без самого документа - просто мусор, который при анализе вы можете спокойно игнорировать.
Вам это не нравится? Выбиваете финансирование, пишете новое ТЗ, получает новую систему для реализации "пришедших мыслей".
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2014, 18:01
    #38614580
SERG1257
SERG1257
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Должна ли быть согласованность данных в базе "по умолчанию"
Соглашусь с АнатоЛой другими словами.
Вам не надо отвечать на известный русский вопрос "Кто виноват?",
вам надо отвечать на другой русский вопрос "Что делать?"

Описываете проблему в понятных бизнесу терминах,
описываете возможные неприятные последствия,
описываете возможные пути решения,
согласуете свою докладную записку с начальством
Если возражений нет, то даете ей ход как заявка на доработку.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2014, 19:55
    #38614711
Cane Cat Fisher
Cane Cat Fisher
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Должна ли быть согласованность данных в базе "по умолчанию"
avecЗавожу баг на эту систему, в ответ получаю, что меня просят указать в нем требование, которое не выполнено

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

Например: Обнаружен баг - неверная работа отчетов. Воспроизведение:

1. Добавляем Улицу1 в справочник улиц
2. Добавляем клиента, вносим ему адрес - Улицу1.
3. Вносим оплату этого клиента.
4. Удаляем из справочника улиц Улицу1, якобы ошибочно.
5. Формируем отчет "Приход по кассе за неделю по дням" (подыскать отчет, не использующий справочник улиц)
6. Формируем отчет - приход по кассе за день в разрезе клиентов, с указанием адреса (подыскать отчет с join на справочник улиц)
7. Собственно, баг: сумма за указанный день в п.5 не совпадает с итогом по п.6, поскольку оплата клиента, как и сам клиент, из отчета п.6 пропал вместе с пропавшей улицей.

Предлагается доработка: на п.4 система не должна разрешить удалить улицу, для чего нужно поддерживать ссылочную целостность средствами... ну и т.д.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2014, 21:10
    #38614770
vmag
vmag
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Должна ли быть согласованность данных в базе "по умолчанию"
avec,

По любому через два года никто ничего бесплатно устранять не будет (если автора интересует именно этот вопрос) - это однозначно будет только за новые деньги. Другое дело если бы все эти два года у вас был с разработчиком действующий договор на техническое сопровождение, по которому вы регулярно платили - тогда вы могли бы качать свои права, да и то опять же только в рамках этого договора и на условиях этого договора. А так ситуация примерно такая как если бы вы купили в магазине холодильник, а потом пришли через пять лет и начали качать права, что вам продали холодильник у которого при закрытии двери внутри не гаснет свет - конечно вас пошлют куда подальше и будут правы...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2014, 21:31
    #38614786
vmag
vmag
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Должна ли быть согласованность данных в базе "по умолчанию"
avecДолжна ли база быть в согласованном состоянии,

Практически любая СУБД может реализовать и не согласованную базу как у вас, но и согласованную с поддержкой целостности данных и так далее, стоит только на этапе проектирования поставить / убрать в нужных местах нужные галочки да содать индексы, ключи и связи, но это все опять же прописывается в ТЗ, в данном случае разработчики посчитали (раз в ТЗ этого нет) - то лучше оставить историю изменения документа при удалении самого документа, чем потерять всю историю изменения документа при случайном удалении нужного документа - вот по этому вы и заметили этот факт только через два года, да еще небось и радовались когда случайно удаляли нужный документ, а его история оставалась и можно было всё восстановить за час два создав новый документ по истории старого...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2014, 22:51
    #38614841
avec
avec
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Должна ли быть согласованность данных в базе "по умолчанию"
vmagavecДолжна ли база быть в согласованном состоянии,

Практически любая СУБД может реализовать и не согласованную базу как у вас, но и согласованную с поддержкой целостности данных и так далее, стоит только на этапе проектирования поставить / убрать в нужных местах нужные галочки да содать индексы, ключи и связи, но это все опять же прописывается в ТЗ, в данном случае разработчики посчитали (раз в ТЗ этого нет) - то лучше оставить историю изменения документа при удалении самого документа, чем потерять всю историю изменения документа при случайном удалении нужного документа - вот по этому вы и заметили этот факт только через два года, да еще небось и радовались когда случайно удаляли нужный документ, а его история оставалась и можно было всё восстановить за час два создав новый документ по истории старого...

Мне казалось, есть что-то незыблемое в работе хороших айтишников, а по высказываниям я смотрю, что айтишники превратились в унылых строителей. Им не скажешь, что надо перед окраской, например, оштукатурить или грунт нанести, ну или хотя бы старую краску счистить - так они и красят по отколупливающейся и приговаривают: "вы ж в ТЗ не написали."... грустно
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2014, 23:17
    #38614851
АнатоЛой
АнатоЛой
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Должна ли быть согласованность данных в базе "по умолчанию"
avecМне казалось, есть что-то незыблемое в работе хороших айтишников, а по высказываниям я смотрю, что айтишники превратились в унылых строителей.

Когда нужен к зиме - он может быть и непокрашенный, но тёплый.
А если коров можно заселять только в следующем году - всё будет с иголочки, и даже бахилы для коров...
Вам ведь такая БД нравится?

avecИм не скажешь, что надо перед окраской, например, оштукатурить или грунт нанести, ну или хотя бы старую краску счистить - так они и красят по отколупливающейся и приговаривают: "вы ж в ТЗ не написали."... грустно

Вы присутствовали, когда несколько лет назад команда с обеих сторон согласовывала, что нужно сделать? Нет? Тогда не судите. Может коровник нужен был к зиме.

Мы всего лишь пытались подсказать, что мир не однополярный. Какой мотив у айтишников, которых вы просите "исправить ошибки" сейчас, делать это? Они точно должны это делать?

П.С.:
"Кощей не злой - у него работа такая" (с) НеМой
"Смерть, даже врага, должна вызывать слёзы. Иначе что мы за люди..." (с) Ник. Горькавый "Возвращение астровитянки".
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2014, 23:18
    #38614854
АнатоЛой
АнатоЛой
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Должна ли быть согласованность данных в базе "по умолчанию"
АнатоЛойКогда коровник нужен к зиме.... далее по тексту
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2014, 23:21
    #38614856
avec
avec
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Должна ли быть согласованность данных в базе "по умолчанию"
АнатоЛойМожет коровник нужен был к зиме.


Ну так его без фундамента что ли делать???
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2014, 23:59
    #38614871
АнатоЛой
АнатоЛой
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Должна ли быть согласованность данных в базе "по умолчанию"
avecАнатоЛойМожет коровник нужен был к зиме.


Ну так его без фундамента что ли делать???
Какой вы непробиваемый.
Коровник нужен к зиме, остался месяц, бетонных блоков нет, заливать бесполезно - уже не выстоится.
Ещё раз задаю вопрос: вы участвовали при подписании ТЗ?
Если да, то всё хорошо: все важные вещи вы же в ТЗ прописали?
Если нет, то советы вам уже дали:
1) или оформляйте новые требования/ТЗ;
2) или ищите нарушение требования, указанного в ТЗ, которое таки потребует использования ссылочной целостности;
3) или "меняйте работу" (с) анек про программиста и запрос.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.04.2014, 19:24
    #38615820
alexeyvg
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Должна ли быть согласованность данных в базе "по умолчанию"
avecЗавожу баг на эту систему, в ответ получаю, что меня просят указать в нем требование, которое не выполнено. "Если такого нет, то значит система работает штатно".

У меня волосы шевелятся от такого подхода, но не могу найти что возразить...Нормальный подход.
avecДолжна ли база быть в согласованном состоянии, с нормально прописанными хотя бы элементарными констрейнтами, внешними ключами, даже несмотря на то что в ТЗ такого ПРЯМОГО требования нет?Нет, "констрейны" - инструмент для реализации бизнес-требований.

Например, историю изменений документа, возможно, нужно хранить без документа, соответственно констрейн не нужен.

Но естественно есть понятие "хорошая практика", так что в чём то вы правы, если говорить не конкретно про историю, а вообще.

Насчёт "обязательно должно быть прописано в ТЗ" - не согласен.

Есть общепринятые вещи, "хорошая практика".
Допустим, не было в ТЗ требования к формированию имён таблиц и переменных, это же не значит, что можно сделать все имена GUID-ами. То же можно сказать, например, про структурирование кода, модульность.

Или это получится не ТЗ, а "задание тупому кодеру", до уровня элементарных функций на несколько строк, то есть собственно практически готовая программа, остаётся только закодить.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.04.2014, 22:22
    #38615913
vmag
vmag
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Должна ли быть согласованность данных в базе "по умолчанию"
alexeyvgИли это получится не ТЗ, а "задание тупому кодеру", до уровня элементарных функций на несколько строк, то есть собственно практически готовая программа, остаётся только закодить.

Речь вообще-то не о программе, а о структуре базы данных, а если еще точнее то про то, что нет каскадного удаления, по этому есть мусор (только и всего), причем еще не ясно - хорошо это или плохо... Можно решить данную проблему несколькими запросами на удаление мусора и всё (в зависимости от длины потерянного дерева, а потом зайти в конструктор схемы и проставить каскадное удаление на будущее), при этом преподать это как рац предложение, заработать бабла и повесить на грудь медаль...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
16.04.2014, 10:55
    #38616184
Mikle83
Mikle83
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Должна ли быть согласованность данных в базе "по умолчанию"
ТС. Согласованность - очень сложный вопрос, особенно в вашем случае.
Удаление документа не тривиальная задача, т.к. не понятно (и, вероятно) ТЗ этот вопрос не описывало - что делать, когда идет попытка удалить документ, имеющий подчиненные сущности.

Вариантов сходу несколько:
а) не давать удалять, пока существует хотя бы одна связанная сущность;
б) удалять, и удалять в том числе связанные записи;
в) удалять, не удаляя связанные записи;

Каждый из них имеет свои плюсы и минусы в зависимости от конкретной бизнес-модели .

Я бы, к примеру, сформировал четвертый вариант: не удалять, а переносить в архив.
ИМХО физическое удаление в БД - зло. Всегда должна быть возможность данные восстановить.

Так что требовать наличие "констреинтов" по умолчанию - это мягко сказать не верно.

[QUOTE]Завожу баг на эту систему, в ответ получаю, что меня просят указать в нем требование, которое не выполнено.[QUOTE]
А вот тут извините, но разработчик прав.

По вашей же аналогии: дом сдан, но вы через два года требуете поставить финские стеклопакеты , вместо установленных стандартных кривых русских, а также поменять ванную на ванную с гидромассажем. При этом в спецификации было просто указано "стеклопакеты" и "сантехника" и стоимость рассчитывалась исходя из стандартных.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Должна ли быть согласованность данных в базе "по умолчанию" / 14 сообщений из 14, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 247ms
Закрыть
start [/forum/topic.php?fid=32&tablet=1&tid=1540924]:
 0ms
get settings:
 7ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 143ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 52ms
get tp. blocked users:
 2ms
others: 10ms
total:  247ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]