powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как лучше хранить и сделать поиск по большому кол-ву данных
19 сообщений из 44, страница 2 из 2
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37703118
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softrixЭто так, но при условии, что в любой момент времени забронирован весь год. Тогда и данные хранить смысла нет. :)
статус 2 (свободен)

Хранить надо события, которые произошли.
А не резервировать место, под события, которые возможно произойдут
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37703125
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softrixможно их в архив скидывать в конце года, чтобы таблицу не растить.

Зачем? У тебя аллергия на большие таблицы?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37703254
softrix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Gloryстатус 2 (свободен)

Хранить надо события, которые произошли.
А не резервировать место, под события, которые возможно произойдут


Храним событие:
Есть бронь с 01.05 по 05.05
И бронь с 09.05 по 10.05
соответственно храним эти 2 события.
И как по ним поиск сделать?

Dimitry Sibiryakov Зачем? У тебя аллергия на большие таблицы?.


Ну мне кажется, что чем больше таблица тем медленнее она работает и медленнее по ней поиск, хотя может я не прав?
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37703305
Gloreus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softrix,

Насколько большая? 1м записей - не много, при правильных индексах всё будет летать
у меня база около 30г, таблички по 16млн. есть, живём :)
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37703340
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softrixЕсть бронь с 01.05 по 05.05
И бронь с 09.05 по 10.05
соответственно храним эти 2 события.
И как по ним поиск сделать?
Поиск чего ?
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37703426
softrix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
GloryПоиск чего ?
Ну к примеру, нужен свободный номер с 06.05 по 08.05
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37703446
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softrixНу к примеру, нужен свободный номер с 06.05 по 08.05
Это элементарная задача не пересечение периодов
where period1_beg > period2_end and period1_end < period2_beg
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37703491
softrix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
GloryЭто элементарная задача не пересечение периодов
where period1_beg > period2_end and period1_end < period2_beg

Вы не можете писать конкретнее!?
period1_beg,period2_end,period1_end,period2_beg - что из этого переменная содержащая искомую дату, а что столбец таблицы?
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37703497
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softrixperiod1_beg,period2_end,period1_end,period2_beg - что из этого переменная содержащая искомую дату, а что столбец таблицы?
Это два периода
Все равно, что из них что
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37703498
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Только при пересечении периодов нужно аккуратно посмотреть чтобы с какой-то стороны были <= >= а с другой чистые < >. В школе на математике рисуют отрезки одна точка сплошная, другая - выколотая.
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37703518
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GloryЭто два периода
Все равно, что из них что
А будут при таком поиске использоваться индексы?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37703570
softrix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
GloryЭто два периода
Все равно, что из них что
Таблица содержит 2 события
бронь с 01.05 по 05.05 (статус 2)
бронь с 09.05 по 10.05 (статус 2)
Нужно найти свободный номер с 06.05 по 08.05

Если сделать так:
select room_id from shedule where period_end > 06.05 and period_start < 08.05 and status_id=2

Чет чепуха выходит. В этот запрос попадает первая бронь. И даже если бы не попадала, то максимум мы получим пустой результат если таблица содеждит только брони, а как свободный номер получить? Чет я запутался вообще.
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37703592
softrix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ага вроде сообразил.

Можно искать номера которые на эти даты забронированны и вычитать их из выборки
типа

SELECT * from rooms where id not in (select * from shedule where period_start <= '06.05' and period_end >= '08.05' )

Glory, Вы это подразумевали?
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37703595
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Недавно обсуждали.
http://www.sql.ru/forum/actualthread.aspx?tid=922331

2 Glory
Мое мнение: периоды здесь невыгодны. Лобовое решение - материализация в виде строчки на каждый день для каждого номера проще для восприятия, а значит написания, тестирования и поддержки. Плюс запрет накладок через ограничение уникальности проще и надежнее чем исключение через триггер.

softrix Нужно найти свободный номер с 06.05 по 08.05
Код: sql
1.
2.
3.
4.
5.
6.
select * from rooms r where not exists (select * from booking b where b.room_id=r.room_id and 
-- вариант Glory с периодами
not (book_end<=06.05 and 08.05<=book_start)
-- лобовой вариант 
book_date between 06.05 and 08.05
)
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37740806
SirMix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
сделал бы две таблицы:

1) Текущее состояние номера
2) История

вторая таблица есть ничто иное как лог изменений состояний номера с датой начала и конца состояния.
при изменении состояния - в таблице истории закрываем старое состояние датой изменения и ложим новую строчку с датой изменения+секунда/час/день/месяц - в общем минимальная неделимая единица для этой даты - все!
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37741152
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SirMixсделал бы две таблицы:

1) Текущее состояние номера
2) История

вторая таблица есть ничто иное как лог изменений состояний номера с датой начала и конца состояния.
при изменении состояния - в таблице истории закрываем старое состояние датой изменения и ложим новую строчку с датой изменения+секунда/час/день/месяц - в общем минимальная неделимая единица для этой даты - все!Текущее состояние номера конечно нужно, но к задаче это не относится. Это как бы просто карточка номера, понятно, что она есть.

История здесь не нужна, нет же задачи получить реальное использование номера.
Тоесть может такая задача и есть, но вопрос не про неё.
SERG12572 Glory
Мое мнение: периоды здесь невыгодны. Лобовое решение - материализация в виде строчки на каждый день для каждого номера проще для восприятия, а значит написания, тестирования и поддержки. Плюс запрет накладок через ограничение уникальности проще и надежнее чем исключение через триггер.По моему тоже, номеро-дни более правильное решение таких задач...

К тому же, более просто решаются более сложные задачи, типа номер забронирован с 1 до 15, при этом с 1 по 5 там будет жить 2 человека, а с 6 нужно поставить ещё койку.
И всё это относится к одной брони.
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37741529
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softrixЕсть задача сделать для сети отелей поиск свободного номера по дате.
Есть наверное более простое решение!?
не простое, но правильное:
операции:
номер занят дата время
номер свободен дата время
номер зарезервирован дата время
статус расчитывать
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37741808
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softrix,

Насчет периодов тебе правильно подсказали. Но учитывай особенность продления клиентом пребывания в номере. И вообще там есть целая куча моментов. Поэтому для начала пообщайся с администраторами отелей, думаю откроешь много нового в этом направлении. Я как-то сталкивался но неплотно, поэтому и посылаю к тем у кого найдешь ответы по структуре и методам работы. Зная это уже можно лепить таблицы. За оптимизацией набросков можешь приходить на форум.
...
Рейтинг: 0 / 0
Как лучше хранить и сделать поиск по большому кол-ву данных
    #37747310
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softrix, Вы извините, но как то странно рассуждаете о бронировании (о планировании работы производственного участка вашего предприятия). Для того, чтобы бронировать, Вы должны предоставить свободный ресурс для бронирования, правильно? Бронирование отнимает кусочки этого ресурса, но какие-то кусочки остаются все еще, правильно? А Вы рассуждаете о занятых кусочках при решении задачи бронирования все еще свободных)) Очень странно.
...
Рейтинг: 0 / 0
19 сообщений из 44, страница 2 из 2
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как лучше хранить и сделать поиск по большому кол-ву данных
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]