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