> 1. FAST = TRUE — на сколько я знаю, на самом деле был такой параметр, только он никак не был связан с > разбором SQL
Опа, это такой есть?
> 3. 50 на 50, надо смотреть в первую очередь план, если статистика у вас нормальная.
Статистика для большинства это вообще нечто из разряда фантастики :)
> 4. При хорошем знании оптимизатора и базы почему нет? Мне, например, для своей базы, достаточно > посмотреть на не очень навороченный запрос, чтобы понять будет TAF или нет.
Ага, при хорошем знании базы. Если базу хорошо знаешь таких вопросов даже не появляется.
Чаще бывает:
— Вот запрос в моем приложении тормозит. Как его переписать?
> 5.…
Я и не говорю что всегда надо. Но никто же никогда вообще не делает. Несмотря на то как временная таблица используется.
>6. Внешний ключ ВСЕГДА требует unique index в родительской таблице. Или я не так вас понял?
Я про индекс в дочерней вообще-то.
Опрос это вообще ни о чем. Выборка слишком маленькая и специфичная.
Посмотрите резюме, вакансии где-нибудь на hh.ru и увидите реальную распространенность. И сразу станет понятно что на таких языках проект можно делать только для врагов, чтобы они потом с ним всю жизнь мучались.
Зачем разрабатывать на таких языках?
Проект после разработки еще и поддерживать кто-то должен.
Уволится часть команды и что делать? Где новых людей искать?
Если нормализовать все, то мы получим огромный набор таблиц типа
Таблица Имя
Таблица Фамилия
Таблица Отчество
Ведь и имена и фамилии и отчества часто повторяются. Нормализовать всегда имеет смысл до определенной грани.
Ситуация «Не скажу» не всегда возможна. К примеру записываясь к врачу так ответить точно нельзя. Если мы такое допускаем, то надо сразу это предусматривать. А объявив справочник нерасширяемым мы сильно упрощаем и дизайн БД и работу с ним.
Справочник понятие логическое, а таблица физическое. Теплое и мягкое.
Я к справочникам отнес вообще все кроме основных сущностей. В начале проектирования о них обычно можно не задумываться и навешивать на схему позже. Ну и описал эту самую систему «навешивания»
Расширяемый отличается тем что можно добавлять в него значения. Но при этом не заводим отдельную таблицу.
От дубликатов избавляемся на уровне интерфейса с выпадающим списком вариантов. Требовать от пользователя вводить каждый раз уникальный код жестко слишком.
Про <товар> это зависит от того чего проектируем. В какой-нибудь логистической системе это не что иное как справочник.
То есть если кратко может быть все что угодно :)
И любое поведение будет неправильным.
Обзор подобных случаев был бы гораздо интереснее чем простенькое описание поведения в штатной ситуации.
Не так часто, это от области работы сильно зависит.
Я только с такими и работаю.
Получается что для простейших действий, например, взять строку - показать, обновить то что ввел юзер. Это проще делать через объектную модель.
А вот сформировать отчет, загрузить/выгрузить данные во внешний источник, рассчитать нечто. Это все делается через хранимые процедуры и никак иначе. Главное вовремя разобраться что и как делать лучше.
Да. Хотя я бы еще добавил новости, но не вообще об автомобилях, а о скидках, спецпредложениях в салонах. С RSS, возможностью фильтрации.
Если такие новости будут аккуратно сделаны, то есть не просто 2 рекламные строчки, а подробно с цифрами и сроками действия. Тогда на них будут подписываться. И вы получите стабильный поток посетителей, которых интересует именно покупка машины.
Убрать надо. Рубрики новостей на главной странице сайта о продаже автомобилей вообще не нужны.
Если хотите новости, по сделайте ссылку "Новости".
Заодно уберите блоги гороскопы и прочее. Web2.0 конечно круто итд, но совсем не в тему.
Каша на главной странице.
Вы наверно хотели вместить на нее все сразу.
И в результате ничего не понятно. Если сайт о продаже то продажи должны выделяться, а все остальное не важно. Где-нибудь отдельными разделами по ссылкам.
cars.auto.ru отличный пример для вдохновения.
А чем отличаются ряд ссылок под логотипом от раздела рубрики немного ниже?
Действительно. Плохо сформулировал.
Надо бы так: «Никто не задумывается ни о 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 год -> получил результат.
Если такие новости будут аккуратно сделаны, то есть не просто 2 рекламные строчки, а подробно с цифрами и сроками действия. Тогда на них будут подписываться. И вы получите стабильный поток посетителей, которых интересует именно покупка машины.
Если хотите новости, по сделайте ссылку "Новости".
Заодно уберите блоги гороскопы и прочее. Web2.0 конечно круто итд, но совсем не в тему.
Вы наверно хотели вместить на нее все сразу.
И в результате ничего не понятно. Если сайт о продаже то продажи должны выделяться, а все остальное не важно. Где-нибудь отдельными разделами по ссылкам.
cars.auto.ru отличный пример для вдохновения.
А чем отличаются ряд ссылок под логотипом от раздела рубрики немного ниже?