|
|
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
F#, В таких случаях меня учили отвечать "патамушто" и "из конструктивных соображений". Смотря кому отвечаем. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2013, 11:04 |
|
||
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
Arhat109, На предыдущий совет про "по коду расставить ...": ничто так не отрезвляет барина, как ответ проги "Упс. Данная опция отключена по п.1.2.3 ТЗ по указанию ... см. мантис, вопрос 5625, было в ревизии 7890", особенно когда он сам же и нарывается на сообщение. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2013, 11:08 |
|
||
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
ъ Почему в БД не рекомендуется иметь несколько разных таблиц одинаковой структуры? Такой рекомендации нет. Но иногда несколько таблиц одинаковой структуры косвенно укажут специалисту на возможные ошибки проектирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2013, 13:11 |
|
||
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
Cane Cat FisherНо иногда несколько таблиц одинаковой структуры косвенно укажут специалисту на возможные ошибки проектирования. Например наш главный конкурент имеет повторение структуры на каждый год. Т.е. его таблички просто копируются для данных каждого года. И всякое изменеие структуры влечет перестройку всех таблиц и данных по годам... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2013, 14:12 |
|
||
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
skyANAF#Надо ему просто объяснить что при любом дублировании куча работы будет дублироваться при каждом внесении измений.Например? Не вижу особой разницы, если создать четыре представления и через них работать. Какие 4 представления? На какой субд? При этом в любом случае при изменении структуры надо будет менять n таблиц. Например, в MS SQL updatable views обладают существенными ограничениями. И главное, зачем это всё? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2013, 15:11 |
|
||
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
F#Какие 4 представления?v_Работнике, v_СтроительствоКоммунизма, v_Косьба и v_Забивание ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2013, 19:45 |
|
||
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
skyANA, а зачем столько вью? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2013, 22:15 |
|
||
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
Поможет только смена работы. Если шэф не шарит в основах СУБД и его ещё не уволили, то скорее всего у него очень большой орган есть которому Вы не противопоставите даже Нобелевскую премию. Есть правда вариант деградировать до уровня шэфа и отращивать десятилетиями такой же орган, но... Может проще работу поменять :) На своём опыте - 2.5 года такой "работы" ничего толкового не дали. Поменял работу - совсем другое дело. ЗЫ: Ещё ж такой момент: если он не понимает таких простых вещей, то что уже говорить за реально сложные?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2013, 17:46 |
|
||
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
BJValentineПоможет только смена работы. Если шэф не шарит в основах СУБД и его ещё не уволили, то скорее всего у него очень большой орган есть которому Вы не противопоставите даже Нобелевскую премию. Есть правда вариант деградировать до уровня шэфа и отращивать десятилетиями такой же орган, но... Может проще работу поменять :) На своём опыте - 2.5 года такой "работы" ничего толкового не дали. Поменял работу - совсем другое дело. ЗЫ: Ещё ж такой момент: если он не понимает таких простых вещей, то что уже говорить за реально сложные?! Это не начальник! это - заказчик ! И заказчик, на своём каком-то, "не профессиональном" уровне - достаточно "шаряший", и "с желанием", в будующем, какие-то возникающие вопросы - решать самому : запросики, там, пописывать, отчеты делать и т.д. Отсюда и вот такие его требования. ъда, вот, в том-то и дело, что "на структуру" ему "не всё равно" это одно из его требований - "я должен понимать структуру, и "что и где", в этой структуре - обозначает" если вернутся опять к той, предложенной им схеме то начиналось всё с того, что половину атрибутов работника (Адрес например, для определённости) - он "запихнул" в эти таблицы работ ("Косьба", "Забивание"). С этим, мне удалось его "переубедить, простым примером - то что, в конце концов, всё закончится тем, что у одного и того же работника, в разных таблицах работ - будет разный Адрес, и никто, никогда об этом не узнает ... То есть - не "напирая" на различные "словеса", типа "нормализация", "дублирование данных" и т.д. ... - просто на примере, "чем это в конце концов заканчивается" :) Вот, что-то такое же, "простое и убедительное" я хотел услышать по сабжевому вопросу: - выбор между 2-мя принципиально разными возможностями построения схемы данных, в части "Работ". Одна общая таблица + справочник типов работ или - отдельная таблица, под каждый тип работы И, насколько я понял из обсуждения, никаких таких простых слов/примеров, для данного вопроса - нет. И 1-ый и 2-ой вариант - имеют право на существование, и решаться должно, в каждом конкретном случае, "персонально". ...правда, из каких критериев "решаться" - всё равно не понятно ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2013, 10:34 |
|
||
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
Если заказчик, то надо потерпеть его. Грустно это когда заказчик лезет во внутреннюю организацию программы не имея внушительного опыта проектирования. Ну, а что поделать? Сделай ему велосипед с квадратными колёсами как он хочет - единственное что приходит в голову. А за поддержку сего продукта денежку брать не забывай. Если потребуется таки добавить ещё один или (что ещё лучше) несколько типов работ - бери много денег. Потому, что в этом случае объём работ существенно вырастет: - Моделирование новых таблиц (включая индексы, ключи, триггеры etc.); - Создание скриптов для этих таблиц, модификация/создание представлений; - Администрирование доступа к новым объектам; - Настройка репликации этих таблиц; - И прочее, прочее, прочее. Справа от каждого пункта надо написать цену. Моё мнение - дураки должны платить, причём прямо пропорционально своей тупости (а лучше по экспоненте! ))) ). Природа наказывает каждого за тупость, это нормально и это хорошо :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2013, 11:54 |
|
||
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
Если он такой "шарящий", пусть себе сам программу пишет ))) Видать не достаточно шарящий всё-таки. А структуру детскую просит скорее всего потому, что запросы писал только в мастере. У меня уже подобных ситуаций было 100500, возможно твоя ситуация иная, смотри сам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2013, 11:58 |
|
||
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
BJValentineЕсли заказчик, то надо потерпеть его. Грустно это когда заказчик лезет во внутреннюю организацию программы не имея внушительного опыта проектирования. Ну, а что поделать? Сделай ему велосипед с квадратными колёсами как он хочет - единственное что приходит в голову. ... ну да, вот так сейчас и решил делать (точнее - сделал) :) сказал ему, что - твоя схема имеет "один большой плюс" - ты её выбрал сам! и за все "негаразды" с ней - будеш отвечать сам! может и не будет "негараздов" - а может и будут ... я считаю, что мой вариант (2-ой который, с общей таб.+справочник) - лучше, но аргументированно это доказать - не могу ... значит делаем так, как ты настаиваеш ... вот ... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2013, 12:19 |
|
||
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
Второй вариант лучше конечно. Тут уже расписали вдоль и поперёк почему. Но дядя похоже не достаточно хорошо умеет писать запросы поэтому ему нада структура попроще. Одна таблица на все типы работ это выше уровень абстракции чем для каждого типа работ своя таблица. А не все умеют работать с абстракциями. Это то и отличат программиста от того, кто заказывает программы. Это как моего коллегу заставляли для каждого справочника писать отдельную форму, а он написал один компонент реализующий функционал ЛЮБОГО справочника. Понятно, что для поддержки и развития этой конфетки надо ум хороший, но есть места где ума дефицит. Вот и получается, что не имея денег покупают запорожец, ну а мэрса хотят все без исключения ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2013, 12:34 |
|
||
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
Можно придумать такой тип задач, где вариант 1 будет лучше. Пример - случаи, когда косьба и забивание являются суть разными вещами и обладают своим набором атрибутов. Но даже в этом случае вопрос, что лучше - делать разряжённую общую таблицу или сводить общие атрибуты в одну, а на остаток делать свои таблицы-расширения, открыт. Логическое отличие между вариантом 1 и 2 - возможность на общую таблицу констрэинтов на уникальность понавешать. В конечном счёте всё упрётся в вопросы производительности, т.е. в физический дизайн, частью которого дизайн таблиц и является (можно же действительно понаделать дополнительных view'х, и для приложений различия между вараинтом 1 и 2 (с учётом замечания про constraints) просто исчезнут). Отталкиваться надо от функциональности системы. Какие запросы будут использоваться чаще всего. Только в этом свете правильно выявляются сущности, которыми оперирует система. Если запросы в основном будут сразу по всем типам работ (что вероятней всего, это зависит от ваших задач), эффективней будет вариант 2; если работы разных типов никогда совместно не участвуют в запросах/выборках, то эффективней вариант 1. Разница в стоимости - раза в два. Можно (если СУБД умеет) поиграться с партиционированием по типу работ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2013, 14:19 |
|
||
|
Нормализация для "тёмных" :)
|
|||
|---|---|---|---|
|
#18+
CawaSPb, авторЕсли запросы в основном будут сразу по всем типам работ (что вероятней всего, это зависит от ваших задач), эффективней будет вариант 2; если работы разных типов никогда совместно не участвуют в запросах/выборках, то эффективней вариант 1. Разница в стоимости - раза в два. Правильно разработанный (кластерный) индекс уменьшит стоимость второго варианта почти в два раза :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2013, 16:02 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38110811&tid=1541385]: |
0ms |
get settings: |
7ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
42ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 242ms |
| total: | 375ms |

| 0 / 0 |
