|
|
|
Битва с денормализацией и прочее. Кто как решает?
|
|||
|---|---|---|---|
|
#18+
В процессе эксплуатации биллингов и техучётов стал замечать расползание концепции. Пользователи технологи и прочие привелегировнные (корректирующие справочники) строят собственное видение работы с данными. 1) Если существует поле с более или менее либеральным типом данных типа varchar2, оно будет сползать в сторону нарушения атомарности. IDUSERSTATUSCOMMENT0VSTEPANKOVUNLOCKEDVSTEPANKOV входит в группу ФГ1 ФГ21EFABRISHEVALOCKEDзаблокированный Фабрищева бывш. Лозицкая 2ELOZITSKAYALOCKEDзаблокированный (Попытка внести неявную связь между двумя строками 1 и 2. Попытка создать ссылочный ключ для В.Степанкова). 2) Альтернативный NULL. Технологи упорно инициализируют в справочниках поля, даже в тех случаях, когда в этом нет особой необходимости. Пример. IDCATEGORY0NULL1[нет категории]2-----3....4Бухгалтерия5Технолог (В данном случае, типы 1,2,3 равнозначны и не имеют привязки ни к чему. Появляются спонтанно.) 3) Перенос части ключевой информации в неключевые поля. Пример. IDGROUPComment0ФГ1ФГ1-основной пользователь1ФГ2ФГ2-пользователь с правом корректировки услуг По каментам иногда строится отчётность, что может вызвать появление аномалий. Буду рад различным советам, и примечаниям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2008, 14:01:10 |
|
||
|
Битва с денормализацией и прочее. Кто как решает?
|
|||
|---|---|---|---|
|
#18+
> В процессе эксплуатации биллингов и техучётов стал замечать расползание концепции. Не может расползаться то, чего нет. В данном случае есть изначально кривая структура данных, с которой пользователи пытаются бороться. При проектировании были сделаны типичные ошибки: > ID,USER,STATUS,COMMENT не реализована темпоральность; не реализована регистрация пользователей; > ID,CATEGORY не реализовано (насколько об этом можно судить по данным) штатное расписание; > ID,GROUP,Comment не реализовано ограничение доступа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2008, 14:58:25 |
|
||
|
Битва с денормализацией и прочее. Кто как решает?
|
|||
|---|---|---|---|
|
#18+
> Автор: mayton > В процессе эксплуатации биллингов и техучётов стал замечать > расползание концепции. Пользователи технологи и прочие привелегировнные > (корректирующие справочники) строят собственное видение работы с данными. > Не давайте обезьяне гранату. Немного здоровой бюрократии не повредит: лишить привиллегий DDL-админа (если СУБД позволяет) людей, которым квалификация не позволяет админить, выделить группу проектирования, с которой согласуются все изменения структуры. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2008, 15:36:16 |
|
||
|
Битва с денормализацией и прочее. Кто как решает?
|
|||
|---|---|---|---|
|
#18+
авторПользователи технологи и прочие привелегировнные (корректирующие справочники) строят собственное видение работы с данными. - внести в документацию вышеобозначенные проблемы - сделать документацию общедоступной, в удобном для пользователей виде - провести обучающий семинар где разъяснить вышеназванные проблемы и пути их решения. -- „Истина — это вовсе не то, что можно убедительно доказать, это то, что делает всё проще и понятнее“ — Антуан де Сент-Экзюпери ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2008, 01:06:01 |
|
||
|
Битва с денормализацией и прочее. Кто как решает?
|
|||
|---|---|---|---|
|
#18+
Senya_LНе давайте обезьяне гранату. Немного здоровой бюрократии не повредит: лишить привиллегий DDL-админа (если СУБД позволяет) людей, которым квалификация не позволяет админить, выделить группу проектирования, с которой согласуются все изменения структуры. Увы, это не в моих силах. Изменения вносятся технологами, кандидатуры которых уже выбраны и других у нас не будет (госпредприятие). Я могу лишь аккуратно покрутить триггеры на вставку и обновление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2008, 10:09:38 |
|
||
|
Битва с денормализацией и прочее. Кто как решает?
|
|||
|---|---|---|---|
|
#18+
maytonSenya_LНе давайте обезьяне гранату. Немного здоровой бюрократии не повредит: лишить привиллегий DDL-админа (если СУБД позволяет) людей, которым квалификация не позволяет админить, выделить группу проектирования, с которой согласуются все изменения структуры. Увы, это не в моих силах. Изменения вносятся технологами, кандидатуры которых уже выбраны и других у нас не будет (госпредприятие). Я могу лишь аккуратно покрутить триггеры на вставку и обновление. А кто ты такой, чтобы что то крутить? Звучит резко, но по сути, правила диктуют не IT специалисты, а бизнес. Пусть работают как им удобно. В данном случае я не вижу, что плохого в заведённых данных, кроме того, что лично тебе они не нравятся. Вот когда ты продемонстрируешь пользователям, что они заводят некачественные данные которые создают проблемы ИМ, а не тебе, т.е. какие то отчёты формируются неправильно и т.п. Тогда и можно будет говорить о мерах. Возможно система была изначально не настроена, так что технологам приходится выкручиваться заполняя справочники самостоятельно. Ну и обучение следует провести. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2008, 14:55:25 |
|
||
|
Битва с денормализацией и прочее. Кто как решает?
|
|||
|---|---|---|---|
|
#18+
explaВ данном случае я не вижу, что плохого в заведённых данных, кроме того, что лично тебе они не нравятся. Тоесть вы считаете, что нет повода для беспокойства? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2008, 14:58:24 |
|
||
|
Битва с денормализацией и прочее. Кто как решает?
|
|||
|---|---|---|---|
|
#18+
maytonexplaВ данном случае я не вижу, что плохого в заведённых данных, кроме того, что лично тебе они не нравятся. Тоесть вы считаете, что нет повода для беспокойства?То что я вижу - в примерах (1) и (3) - это просто попытка пользователей обозвать это как-то понятно для себя. Единственная проблема может быть с пунктом (2) - здесь может понадобиться сливать эти названия в одно. Решать проблему можно разными способами. 2.1 - назначить ответственного за поддержание справочника в адекватном состоянии. Этот человек должен смотреть новые пункты, колторые добавлены в раздел и при необходимости изменять их или сливать с существующими. 2.2 - как уже говорили - Создать соглашение о том как называть такие пункты и придерживаться такого соглашения. Для этого создать документ, провести обучение, можно даже назначить штраф за неверное заведение информации. 2.3 - Ограничить допустимый набор вводимых символов, например, буквами. Но это полностью не решит проблему, потому что могут начать называть вместо "----", "ннн" Лучше всего использовать сразу все вместе. Но это при условии, что это ДЕЙСТВИТЕЛЬНО мешает работе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2008, 15:07:42 |
|
||
|
Битва с денормализацией и прочее. Кто как решает?
|
|||
|---|---|---|---|
|
#18+
maytonexplaВ данном случае я не вижу, что плохого в заведённых данных, кроме того, что лично тебе они не нравятся. Тоесть вы считаете, что нет повода для беспокойства? Беспокойся не о себе или концепции или атомарности, а о бизнесе. Прикинь, чем это может повредить работе пользователей и обрати их внимание на это. Вероятно, тебе ответят, что это не важно. Подумай ещё раз. Если, ты снова считаешь, что это на самом деле важно, обратись к руководству технологов (или к своему руководству, если ранг не позволяет, ведь твой начальник тоже лицо заинтересованное). Мол, с такими данными годовая отчётность будет кривой и т.п.. Пусть тогда руководство решает принимать меры сейчас и строить технологов, или перед отчётом на пару дней напрячь тебя, чтобы ты всё поправил. В общем замалчивать проблему нельзя, но и считать что твоё мнение крайнее тоже нельзя. У руководства могут быть свои планы и руководство не обязано объяснять подчинённым свои решения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2008, 15:13:23 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35713618&tid=1543525]: |
0ms |
get settings: |
4ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
181ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 210ms |
| total: | 462ms |

| 0 / 0 |
