от Barry Williams. =>

Вопрос:
Принцип заполнения таблички View_Unit_Status?
При изменении/добавлении/удалении записей в табличке Apartment_Bookings
1. Кодом (файл-сервер) .
2. Возможностями сервера (клиент-сервер)
3. Как -то еще.
Или это запрос (вьюха)?

Спасибо.

вообще во View разве бывают PK ?
очень похоже на таблицу для разбивания многие-ко-многим, но почему ключ - дата?
к тому же есть прямая связь один-ко-многим от Apartments к Apartment_Bookings
в общем непонятно

Видимо, он просто ошибся в рисовании схемы с PK status_date.

я вообще не стал бы использовать эту схему

"шахматку" букинга можно разворачивать по таблице календарь

Ему нужно просто Верить На Слово!

Вопрос теоретический, без практического наполнения, но все-же для понимания

в схемах на DatabaseAnswers вообще не встречал ничего что годилось бы для практического применения - там просто какой-то стремительный поток сознания. подозреваю что и с точки зрения теоретических основ проектирования БД ценности все это имеет мало.

пару раз заглядывал, порылся, полистал. с содраганием захлопнул браузер и вычистил все из хистори и фэйворитс.

моего понимания теории БД недостаточно для оценки предложенных там решений

ЗЫ

поскольку эксплуатацией объектов недвижимости (и учета отношений аренды) я занимаюсь не теоретически а практически буду рад ответить на вопросы практического порядка

ЗЗЫ

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

Да, совсем старый стал.
Здесь не нашел табличку-календарь, а на соседнем форуме действительно ну очень неоднократно.
Спасибо за напоминание.

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

Благодарю, распечатал, изучаю.

Видимо, пользователей (заказчика) его схемы, все устраивало.
Это как по лесенке:
1. Переход от бумажного блокнотика к Excel-ю.
2. Переезд с Excel на Access(MDB).
3. Переезд с Access(MDB) на сервер SQL.
Причем каждая ступенька сопровождается дозой удовлетворения.

...ни одна из них такой схемой не удовлетворилась бы...
Ну да, после Вас попробуй кого-нибудь удовлетворить.

...да чего там изучать-то...
А что-бы понять, почему так, а не иначе.
Вопросики:
1. Какой контакт в tblBookings, манагер?
2. По какому принципу разнесен адрес по Line-ам?

Спасибо дружище, но нельзя ли вкратце словами, а то мой скайлинк держит меня на "диете"?

По п.1 и п.2 понятно, по ЗЫ только первая строчка.
Остальное: надо учиться, учиться и учиться.

Благодарю за потраченное время.

Да-да-да.
Именно такого материала мне и нужно было. Углубился.
Спасибо.

АААААА...
Мой, сгубленный вредными привычками, мозг не выдержит такой нагрузки и взорвется как граната Ф1.
Спасибо.

очень хорошие вопросы (с) и оба касаются оптимизации того или иного конкретного решения.

да, действительно в большинстве реализаций (системы планирования "Resource usage") лучше брать две даты диапазона а количество дней рассчитывать - но очень много зависит от дальнейшей аналитики и вообще от назначения системы.

1) например, если вы соберетесь рассчитывать стоимость пребывания, услуг и т.п. или иные значения такого рода, выгоднее будет брать именно дни (количество) а не диапазоны. Или, на каом-то этапе работы с данными у вас появится и то и другое :)
1.а) если количество квантуется не в днях (а часах - в сауне, например, или в солярии) также будет выгоднее брать количество а не диапазон 12-09-2010 12:30:55 <> 12-09-2010 12:35:00. (а если возможно дифференцировать "поденно - почасам - помесячно, то тем более - хранить начало, квантор и количество)

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

мое имхо - нужно изначально (в паттернах) максимально зажимать тему, потом чуть отпускать гайки "по месту"

практика показывает, что сквозные адреса и контакты открывает новые горизонты по анализу при больших объемах данных - это уже дэйта майнинг -

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