vadiminfo3. Може случиться так, что много мелких таблиц не всегда выглядит преимуществом при извлечении инфы. Например, найти максимвльную дату из всех работ во втором случае много легче будет, чем объеденить 100 мелких таблиц в одном запросе. Который из-за пп 1 придется еще дорабатвать при каждой новой появившейся вдруг табле в БД.имхается мне, что человеку, который бьет себя пяткой в грудь " не будет ничего добавлятся, век воли не видать ",
это может оказаться главным аргументом - выяснение максимальной даты, получение списка выполняемых работ на заданное время итд итп,
везде, где нужна будет сводная информация, придется строить запрос не по одной таблице,
а объединять столько таблиц, сколько видов работ

пысы: человека, которому "плевать на всякие там нормализации"
не стоит подпускать до проектирования БД,
нарисуйте ему формочки, как ему хочется, и не посвящайте в "кухню БД" :)

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

Author the new oneChopвезде, где нужна будет сводная информация, придется строить запрос не по одной таблице,
а объединять столько таблиц, сколько видов работЗато когда потребуется отчет по одному виду работ, то все будет считаться гораздо шустрее.1. немного быстрее - вполне возможно,
но "гораздо шустрее"... не факт не факт...
надо тестить на конкретных данных и БД
2. у вас есть статистика как часто будет требоваться отчет по одному виду работ и как часто - сводная инфа?
3. по одному виду работ запрос и так будет "шустро выполняться"
Author the new oneИ, с другой стороны, в чем особый ужас построения запроса не по одной таблице, а по нескольким?увеличение объема кода,
увеличение структуры данных
ужаса в этом никакого нет,
просто неудобно, бОльшая вероятность шибки, дополнительная работа,
а ужаса не, нету :)

пысы. какие-то вы термины используете, мне до конца не понятные - "гораздо шустрее", "ужас" :)

Author the new oneУ Вас, похоже, она уже есть :-)кто, она?
Author the new oneChopувеличение объема кода,
увеличение структуры данных
ужаса в этом никакого нет,
просто неудобно, бОльшая вероятность шибки, дополнительная работа,
а ужаса не, нету :)Мне, как программисту, идея боязни кода кажется несколько неожиданной. Ну сделают view на эти таблицы для представления в виде из варианта 2 - ну и что?где вы увидели "боязнь кода"?
у вас проблеммы с пониманием русского языка?
я ведь два раза написал "ужаса нету"

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

например задача построить таблицу " кто чем занимается сейчас " во втором случае тривиальна
и пишется прогом с уровнем подготовки " SQL за 21 день ",
в первом же случае все становится намного "интереснее"
в том числе и потому, что на тривиальнейший вопрос "какие вообще виды работ есть?",
первая схема ответа не дает -
где-то как-то запоминайте, документируйте, сканируйте все таблицы...
зачем этот гемор?

Author the new oneChopпыпысы. как показывает моя личная практика - раньше или позже добавляться будет,
скорее всего захочется что-то добавить сразу после введения в эксплуатацию,
например окажется, что прорабу Васе нужно не просто "косить", а "косить забивая",
все, приехалиЛюди возьмум и добавят еще одну таблицу. Или они должны принести клятву на крови - отныне, мол, в схему не будет добавлено ни одной новой таблицы!и перепишут заодно какую-то часть функционала...
потратят на это время и деньги

прорабу Васе плевать на клятвы РП Пети...

Author the new oneChopкто, она?Статистика, что ж еще.с чего вы это придумали?
Author the new oneChopмне, как ленивому программисту, лениво выполнять лишнюю работу, которую можно сделать проще,
зачем делать лишнюю работу?А почему вы, собственно, уверены, что так будет проще? Мне лично это совершенно неочевидно. (Проще всего вообще счетчики в "фио" напихать, кстати)сочуйствую,
попробуйте еще раз перечитать мой пост,
обратите внимание на фразу "какие вообще виды работ есть?", например
во втором пример пишете обычный дистинкт,
в первом же - проявляете чудеса собственной крутизны программиста БД
Author the new oneChopнапример задача построить таблицу " кто чем занимается сейчас " во втором случае тривиальна
и пишется прогом с уровнем подготовки " SQL за 21 день ",Я, признаться, не вижу проблемы - и в том, и в другом случае все сведется к одинаковому запросу.пример в студию - делов то...
Author the new oneChopв первом же случае все становится намного "интереснее"
в том числе и потому, что на тривиальнейший вопрос "какие вообще виды работ есть?",
первая схема ответа не дает -
где-то как-то запоминайте, документируйте, сканируйте все таблицы...
зачем этот гемор?Вы не подскажете, системный каталог изучают на 22 дне обучения?у вас таки проблемы с русским языком...
это в первом примере на 22-м дне обучения прог сможет написать требуемый запрос,
а не в этом

Author the new oneChopс чего вы это придумали?С ваших бодрых выводов, что и как будет работать.вы ошиблись
Author the new oneChopсочуйствую,
попробуйте еще раз перечитать мой пост,
обратите внимание на фразу "какие вообще виды работ есть?", например
во втором пример пишете обычный дистинкт,
в первом же - проявляете чудеса собственной крутизны программиста БДЕсли выборка из системного каталога для вас - чудеса крутизны, то...для меня - лезть в системный каталог вместо того чтобы нормально спроектировать БД - признак глупости разработчика, а не его крутизны,
крутизной это может считать только тот, кто так делает
Author the new oneChopпример в студию - делов то...Напишите свой - будет аналогично. Хотя, боюсь, от вас всего можно ожидать.понятно - написать не можете,
не я утверждал, что
Author the new oneЯ, признаться, не вижу проблемы - и в том, и в другом случае все сведется к одинаковому запросу.- не мне это это и обосновывать

Cane Cat FisherAuthor the new oneИ, с другой стороны, в чем особый ужас построения запроса не по одной таблице, а по нескольким?В том, что в запросе будет перечислено много таблиц.
Точнее, ужас не в этом, а в том, что во всех запросах, связанным с количеством работы, будет перечислено много таблиц. А таких запросов может быть, например, сто или тысяча. Отчеты, экспорты, SQL-макросы в Excel'ах продвинутых юзеров...да разве ж это ужас?
вспомнил все места, где надо изменить код, сел да переписал...