Зачем разрабатывать на таких языках?
Проект после разработки еще и поддерживать кто-то должен.
Уволится часть команды и что делать? Где новых людей искать?
Если нормализовать все, то мы получим огромный набор таблиц типа
Таблица Имя
Таблица Фамилия
Таблица Отчество
Ведь и имена и фамилии и отчества часто повторяются. Нормализовать всегда имеет смысл до определенной грани.
Ситуация «Не скажу» не всегда возможна. К примеру записываясь к врачу так ответить точно нельзя. Если мы такое допускаем, то надо сразу это предусматривать. А объявив справочник нерасширяемым мы сильно упрощаем и дизайн БД и работу с ним.
Справочник понятие логическое, а таблица физическое. Теплое и мягкое.
Я к справочникам отнес вообще все кроме основных сущностей. В начале проектирования о них обычно можно не задумываться и навешивать на схему позже. Ну и описал эту самую систему «навешивания»
Расширяемый отличается тем что можно добавлять в него значения. Но при этом не заводим отдельную таблицу.
От дубликатов избавляемся на уровне интерфейса с выпадающим списком вариантов. Требовать от пользователя вводить каждый раз уникальный код жестко слишком.
Про <товар> это зависит от того чего проектируем. В какой-нибудь логистической системе это не что иное как справочник.
То есть если кратко может быть все что угодно :)
И любое поведение будет неправильным.
Обзор подобных случаев был бы гораздо интереснее чем простенькое описание поведения в штатной ситуации.
Не так часто, это от области работы сильно зависит.
Я только с такими и работаю.
Получается что для простейших действий, например, взять строку - показать, обновить то что ввел юзер. Это проще делать через объектную модель.
А вот сформировать отчет, загрузить/выгрузить данные во внешний источник, рассчитать нечто. Это все делается через хранимые процедуры и никак иначе. Главное вовремя разобраться что и как делать лучше.
Да. Хотя я бы еще добавил новости, но не вообще об автомобилях, а о скидках, спецпредложениях в салонах. С RSS, возможностью фильтрации.
Если такие новости будут аккуратно сделаны, то есть не просто 2 рекламные строчки, а подробно с цифрами и сроками действия. Тогда на них будут подписываться. И вы получите стабильный поток посетителей, которых интересует именно покупка машины.
Убрать надо. Рубрики новостей на главной странице сайта о продаже автомобилей вообще не нужны.
Если хотите новости, по сделайте ссылку "Новости".
Заодно уберите блоги гороскопы и прочее. Web2.0 конечно круто итд, но совсем не в тему.
Каша на главной странице.
Вы наверно хотели вместить на нее все сразу.
И в результате ничего не понятно. Если сайт о продаже то продажи должны выделяться, а все остальное не важно. Где-нибудь отдельными разделами по ссылкам.
cars.auto.ru отличный пример для вдохновения.
А чем отличаются ряд ссылок под логотипом от раздела рубрики немного ниже?
Microsoft Office 2008 for Mac - спасибо, не знал что такой есть.
Но вопрос а зачем это надо все равно остается открытым.
Как правило есть рабочий офис, винда + домен + куча пользователей.
Новых сотрудников ничему учить не надо. В вакансиях пишем знание Ворд + Эксель.
А так получаем болезненный переход, неделю точно никто работать не будет. Возможно дольше. Новых сотрудников обучать заново надо. Что в вакансиях писать не ясно.
И за все это еще кучу денег отвалить надо.
А что делать с вордовскими, экселевскими и прочими документами сделанными в программах от MS?
Все остальные вам будут присылать документы в таких форматах и от вас хотят в них все получать.
Проект после разработки еще и поддерживать кто-то должен.
Уволится часть команды и что делать? Где новых людей искать?
Таблица Имя
Таблица Фамилия
Таблица Отчество
Ведь и имена и фамилии и отчества часто повторяются. Нормализовать всегда имеет смысл до определенной грани.
Ситуация «Не скажу» не всегда возможна. К примеру записываясь к врачу так ответить точно нельзя. Если мы такое допускаем, то надо сразу это предусматривать. А объявив справочник нерасширяемым мы сильно упрощаем и дизайн БД и работу с ним.
Справочник понятие логическое, а таблица физическое. Теплое и мягкое.
Расширяемый отличается тем что можно добавлять в него значения. Но при этом не заводим отдельную таблицу.
От дубликатов избавляемся на уровне интерфейса с выпадающим списком вариантов. Требовать от пользователя вводить каждый раз уникальный код жестко слишком.
Про <товар> это зависит от того чего проектируем. В какой-нибудь логистической системе это не что иное как справочник.
И любое поведение будет неправильным.
Обзор подобных случаев был бы гораздо интереснее чем простенькое описание поведения в штатной ситуации.
К примеру можно рассмотреть такой случай:
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 отличный пример для вдохновения.
А чем отличаются ряд ссылок под логотипом от раздела рубрики немного ниже?
Но вопрос а зачем это надо все равно остается открытым.
Как правило есть рабочий офис, винда + домен + куча пользователей.
Новых сотрудников ничему учить не надо. В вакансиях пишем знание Ворд + Эксель.
А так получаем болезненный переход, неделю точно никто работать не будет. Возможно дольше. Новых сотрудников обучать заново надо. Что в вакансиях писать не ясно.
И за все это еще кучу денег отвалить надо.
Ради чего?
И там и там только основные возможности поддерживаются.
Все остальные вам будут присылать документы в таких форматах и от вас хотят в них все получать.