Ответы пользователя по тегу Администрирование баз данных
  • Как работают интернет-сервисы по бронированию отелей?

    @Ghostwriter
    Это большая организационная работа по привлечению отелей к сотрудничеству и предоставлению информации о резервировании мест. Очень чётко отлаженное B2B ноу-хау. Priceline (Booking.com) одной из первых начала двигаться в этом направлении и теперь имеет капитализацию в $32B.

    Многие нынешние компании используют API с информацией об отелях от самого Booking.com для бОльшего охвата аудитории, наряду с собственной локальной базой отелей.
    По состоянию на прошлый год, например, небезызвестный Ostrovok.ru использовал несколько сторонних API в дополнении к собственной базе российских отелей.
    Технологическая составляющая B2B сотрудничества может заключаться:
    — в предоставлении отелям SaaS-платформы букинг-сервиса для оперативного (онлайн) резервирования. В этом случае букинг-сервис владеет всей необходимой информацией в реальном времени и может осуществлять резервирование с большой степенью автоматизации. Клиент делает заказ в интерфейсе букинг-сервиса, а автоматизированный бек-офис проводит транзакцию резервирования. При успешной транзакции, клиент получает подтверждение бронирования, а владельцы отеля уведомляются через интерфейс SaaS-платформы о новом резервировании.
    — в выгрузке статистики отеля пост-фактум (через API внутренней системы бронирования самого отеля) через определенные интервалы времени. Само резервирование в таком случае происходит с помощью операторов (или колл-центра, или отдельного подразделения на стороне букинг-сервиса). Операторы получают заявку от клиента, резервируют (при возможности) место в отеле (т.е. решают все организационные вопросы с отелем) и отправляют клиенту букинг-сервиса подтверждение/информацию о невозможности бронирования.
    — в некоем комбинированном способе с разной степенью автоматизации на разных участках.
    Ответ написан
    3 комментария
  • Хорошая ли идея использовать в качестве ID (первичного ключа) мд5 хеш?

    @Ghostwriter
    В вашей задаче, вам не нужен ни MD5, ни автоинкрементный INT, как советовали выше.
    Используйте в качестве первичного ключа бинарное поле и вписывайте в него 16-байтные UUID4-последовательности, а пользователям можете отдавать их в виде 32-символьной HEX-строки.

    Про накладные расходы. По сравнению с int64, каким должен быть автоинкрементный счётчик, размер поля окажется больше всего на 8 байт (в 2 раза), что для вашего случая — совсем не проблема.
    Убедитесь лишь, что ваши индексы всегда умещается целиком в физической памяти, а не хранятся частично или полностью в свопе на диске. Природа UUID такова, что он генерирует равномерно распределенные значения, а значит, поиск по такому индексу будет подвержен эффекту «случайного поиска» (random lookup). И если ваш индекс хотя бы частично хранится на диске, то это может привести к многочисленным random seeks и очень медленной
    Ответ написан
    1 комментарий