Документация теряется элементарно. Проект сделан, сдан. Контора сделавшая его исчезла.
На доделывание отдали другой. Шанс найти документацию стремится к 0.
Ага, надо знать что конфиг есть, и что оно в нем описано. На поиски в лучшем случае день уйдет. Скорее 2-3 дня.
Зачем плодить таки сложности буквально на пустом месте.
Кому мешают это 30 полей? Винты сейчас вообще ничего не стоит. Ограничений на количество столбцов в таблице можно считать что нет.
И что мы выигрываем от такого хранения?
Минусы понятны сразу:
— Непонятная БД
— Непонятное приложение
— Сложный код и там и там
— Необходима внешняя документация
— Тормоза в перспективе
За такое хранение расстрел на месте.
Через год вспомнить что там и как лежит будет невозможно.
Хорошо если документация будет. А если потеряется?
Если нужно 30 полей, пускай будет 30 полей.
Кому они мешают? Пускай лежат себе, с нормальными названиями, комментариями к полям. Никакой документации не нужно и так понятно откуда что брать.
Это далеко не панацея.
Если ускорять каждый запрос создавая именно под него индекс, то мы получим жуткий провал при INSERT или UPDATE по этой таблице.
Возможно стоит изменить запрос так чтобы он использовал какой-нибудь из уже существующих индексов, или создать один накрывающий индекс, который пускай не идеально, но подойдет под большинство запросов.
Вы много видели проектов написанных именно на чистом ANSI SQL?
Всегда и везде используются расширения языка, просто потому что это удобно. Сильно ускоряется процесс разработки, упрощается код, улучшается производительность.
Неизвестно даже что проще. Сделать 2 версии заточенные под конкретные СУБД или одну но совместимую со всем.
А мифическая переносимость нужна очень редко. Какому нормальному человеку потребуется зачем-то менять один сервер на другой?
Это все хорошо в теории. На практике разработка под несколько разных СУБД означает разработку разных БД.
Почти весь код переписывать приходится. Отличия незначительные только на первый взгляд.
> 1. FAST = TRUE — на сколько я знаю, на самом деле был такой параметр, только он никак не был связан с > разбором SQL
Опа, это такой есть?
> 3. 50 на 50, надо смотреть в первую очередь план, если статистика у вас нормальная.
Статистика для большинства это вообще нечто из разряда фантастики :)
> 4. При хорошем знании оптимизатора и базы почему нет? Мне, например, для своей базы, достаточно > посмотреть на не очень навороченный запрос, чтобы понять будет TAF или нет.
Ага, при хорошем знании базы. Если базу хорошо знаешь таких вопросов даже не появляется.
Чаще бывает:
— Вот запрос в моем приложении тормозит. Как его переписать?
> 5.…
Я и не говорю что всегда надо. Но никто же никогда вообще не делает. Несмотря на то как временная таблица используется.
>6. Внешний ключ ВСЕГДА требует unique index в родительской таблице. Или я не так вас понял?
Я про индекс в дочерней вообще-то.
Опрос это вообще ни о чем. Выборка слишком маленькая и специфичная.
Посмотрите резюме, вакансии где-нибудь на hh.ru и увидите реальную распространенность. И сразу станет понятно что на таких языках проект можно делать только для врагов, чтобы они потом с ним всю жизнь мучались.
Зачем разрабатывать на таких языках?
Проект после разработки еще и поддерживать кто-то должен.
Уволится часть команды и что делать? Где новых людей искать?
Если нормализовать все, то мы получим огромный набор таблиц типа
Таблица Имя
Таблица Фамилия
Таблица Отчество
Ведь и имена и фамилии и отчества часто повторяются. Нормализовать всегда имеет смысл до определенной грани.
Ситуация «Не скажу» не всегда возможна. К примеру записываясь к врачу так ответить точно нельзя. Если мы такое допускаем, то надо сразу это предусматривать. А объявив справочник нерасширяемым мы сильно упрощаем и дизайн БД и работу с ним.
Справочник понятие логическое, а таблица физическое. Теплое и мягкое.
Я к справочникам отнес вообще все кроме основных сущностей. В начале проектирования о них обычно можно не задумываться и навешивать на схему позже. Ну и описал эту самую систему «навешивания»
Расширяемый отличается тем что можно добавлять в него значения. Но при этом не заводим отдельную таблицу.
От дубликатов избавляемся на уровне интерфейса с выпадающим списком вариантов. Требовать от пользователя вводить каждый раз уникальный код жестко слишком.
Про <товар> это зависит от того чего проектируем. В какой-нибудь логистической системе это не что иное как справочник.
Это строка длиной 1024 символа.
Если есть индекс по полю, то что именно лежит в этом поле абсолютно не важно.
На доделывание отдали другой. Шанс найти документацию стремится к 0.
Ага, надо знать что конфиг есть, и что оно в нем описано. На поиски в лучшем случае день уйдет. Скорее 2-3 дня.
Зачем плодить таки сложности буквально на пустом месте.
Кому мешают это 30 полей? Винты сейчас вообще ничего не стоит. Ограничений на количество столбцов в таблице можно считать что нет.
И что мы выигрываем от такого хранения?
Минусы понятны сразу:
— Непонятная БД
— Непонятное приложение
— Сложный код и там и там
— Необходима внешняя документация
— Тормоза в перспективе
Через год вспомнить что там и как лежит будет невозможно.
Хорошо если документация будет. А если потеряется?
Если нужно 30 полей, пускай будет 30 полей.
Кому они мешают? Пускай лежат себе, с нормальными названиями, комментариями к полям. Никакой документации не нужно и так понятно откуда что брать.
Если ускорять каждый запрос создавая именно под него индекс, то мы получим жуткий провал при INSERT или UPDATE по этой таблице.
Возможно стоит изменить запрос так чтобы он использовал какой-нибудь из уже существующих индексов, или создать один накрывающий индекс, который пускай не идеально, но подойдет под большинство запросов.
Всегда и везде используются расширения языка, просто потому что это удобно. Сильно ускоряется процесс разработки, упрощается код, улучшается производительность.
Неизвестно даже что проще. Сделать 2 версии заточенные под конкретные СУБД или одну но совместимую со всем.
А мифическая переносимость нужна очень редко. Какому нормальному человеку потребуется зачем-то менять один сервер на другой?
Если сами знаете что это не так?
350 рублей за файл
Программирование на Python
А за 390 рублей можно купить тоже самое на бумаге
Спасибо, нам такое не нужно!
В 95% случаев будет использоваться один индекс с самой большой селективностью.
Почти весь код переписывать приходится. Отличия незначительные только на первый взгляд.
Действительно. Плохо сформулировал.
Надо бы так: «Никто не задумывается ни о PK, ни об индексах во временных таблицах»
Учить, учить и еще учить. Что еще делать :)
Пример select sum() из реальной жизни взят. Только там формула расчета результата посложнее была. Но по сути дела тоже самое.
Опа, это такой есть?
> 3. 50 на 50, надо смотреть в первую очередь план, если статистика у вас нормальная.
Статистика для большинства это вообще нечто из разряда фантастики :)
> 4. При хорошем знании оптимизатора и базы почему нет? Мне, например, для своей базы, достаточно > посмотреть на не очень навороченный запрос, чтобы понять будет TAF или нет.
Ага, при хорошем знании базы. Если базу хорошо знаешь таких вопросов даже не появляется.
Чаще бывает:
— Вот запрос в моем приложении тормозит. Как его переписать?
> 5.…
Я и не говорю что всегда надо. Но никто же никогда вообще не делает. Несмотря на то как временная таблица используется.
>6. Внешний ключ ВСЕГДА требует unique index в родительской таблице. Или я не так вас понял?
Я про индекс в дочерней вообще-то.
Посмотрите резюме, вакансии где-нибудь на hh.ru и увидите реальную распространенность. И сразу станет понятно что на таких языках проект можно делать только для врагов, чтобы они потом с ним всю жизнь мучались.
Проект после разработки еще и поддерживать кто-то должен.
Уволится часть команды и что делать? Где новых людей искать?
Таблица Имя
Таблица Фамилия
Таблица Отчество
Ведь и имена и фамилии и отчества часто повторяются. Нормализовать всегда имеет смысл до определенной грани.
Ситуация «Не скажу» не всегда возможна. К примеру записываясь к врачу так ответить точно нельзя. Если мы такое допускаем, то надо сразу это предусматривать. А объявив справочник нерасширяемым мы сильно упрощаем и дизайн БД и работу с ним.
Справочник понятие логическое, а таблица физическое. Теплое и мягкое.
Расширяемый отличается тем что можно добавлять в него значения. Но при этом не заводим отдельную таблицу.
От дубликатов избавляемся на уровне интерфейса с выпадающим списком вариантов. Требовать от пользователя вводить каждый раз уникальный код жестко слишком.
Про <товар> это зависит от того чего проектируем. В какой-нибудь логистической системе это не что иное как справочник.