Моя задача заключается в следующем. У партнера забираются файлы с ценами, эти файлы могут быть как в XML формате, так и в Excel. У партнера своя база отелей, у нас своя база отелей. Мы должны соотнести отели из их базы к отелям из своей базы. Это делается вручную, например:

SUPER PUPER HOTEL 5* <-> SUPER PUPER 5*

Тоже самое с номерами и размещениями. В XML файлах каждый отель, номер и размещение имеет свой ключ из базы партнера, т.е. в базе привязку ихнего отеля к нашему мы сохраняем так:

1234 <-> 4321

Т.е. primary key их равен primary key наш. 
Все прекрасно пока дело не доходит до excel файлов. Там все представлено текстовыми данными, поэтому нет ключей. А значит единственным способом привязки отеля к ключу из нашей базы будет:

SUPER PUPER HOTEL 5* <-> 4321

Сразу напрашивается структура базы: ключ партнера, название отеля партнера, наш ключ
Но проблема возникает, когда в игру вступает зависимость трех элементов: отель, номер, размещение
Например я привязываю размещение партнера к нашему размещению: Одноместное размещение <-> SINGLE
Это одноместное размщение должно быть привязано к отелю и к конкретному номеру:

SUPER PUPER HOTEL->Стандартный Номер->Одноместное размещение

Т.е. если работаем с ключами, то в базе картина следующая:

1234, 5678, 91011 <-> 9876 (наш ключ один, потому, что структура базы другая и там уже все завязано)

А теперь тоже самое но с текстовыми данными:

SUPER PUPER HOTEL, Стандартный Номер, Одноместное размещение <-> 9876

Но ситуация такая, что в одном отеле может быть десятки видов номеров и десятки видов размещений для каждого номера, т.е. имеем картину:

SUPER PUPER HOTEL, Стандартный Номер, Одноместное размещение <-> 9876
SUPER PUPER HOTEL, Стандартный Номер, Размещение на двоих <-> 6543
SUPER PUPER HOTEL, Стандартный Номер, Размещение на троих <-> 3643
SUPER PUPER HOTEL, Вилла, Размещение 5 человек <-> 9236
SUPER PUPER HOTEL, Вилла, Размещение на 10 человек <-> 6394
SUPER PUPER HOTEL, Номер с видом на море, Одноместное размещение <-> 5236
SUPER PUPER HOTEL, Номер с видом на сад, Двухместное размещение <-> 5194

А теперь представьте, если отелей в базе около 5000.

Думал над алгоритмами хеширования строк MD5, SHA, TTH. Но все они имеют один недостаток - огромное количество байт, которые по размеру больше int'ов, bigint'ов. Т.е. кроме как в текстовое или blob поле их не вставишь. К тому же их длинна зачастую гораздо больше длинны названия отеля, номера или размещения.
Была идея просто тупо пронумеровать все строки в порядке возрастания по мере добавления, но в этом случае ключи партнера начинают пересекаться с искусственными ключами. Отсюда возникает решение - оставить как есть, в текстовом представлении, но мне это дико не нравится. Может быть есть какие-то идеи ?

импорт во вменяемый формат и создание ключа... какие собсно проблемы? соотнести импортированные записи с имеющимся справочником, что ли, сложно?

Добавлено через 59 секунд

И что? Любой более-менее приличной СУБД это не нагрузка.

Ок, попробую еще раз объяснить. Ключи начинают пересекаться с ключами партнера, т.е. с теми ключами, которые приходят в XML формате.


Как например ? Пришло тебе название отеля: CHEBURASHKA HOTEL, а его уже давно как переименовали в KROKODIL GENA CLUB & SPA и именно новое название в нашей базе. Бывает и обратная ситуация. Я уж не стал говорить, что партнеров 12 штук и каждый заводит отели так как ему вздумается...



База данных SQLITE...

P.S.: начинаю думать об избавлении от ключей партнера, и для отелей из XML файлов создавать свои. Но тут возникают другие проблемы:
- снижение скорости запросов из-за строчного сравнения при добавлениии новых отелей. Т.е. если раньше я мог проверить есть ли ключ 123 в базе, то теперь придется сравнивать по названию и я не смогу никогда отследить был ли переименован отель А с ключем 123 в Б.
- невозможность перенести привязки на другую клиентскую машину из-за расхождения в ключах, т.к. порядок импорта может быть разным

Это сообщение отредактировал(а) SABROG - 26.5.2008, 12:23

Не, погодите...
У вас должен быть свой диапазон уникальных ключей, и партнеру выделен свой диапазон. И таблица соответствия: фирма (ваша, партнера-1, партнера-2, ...), оригинальный ключ, общий ключ:



Точно так же - таблица переименований.



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

Это сообщение отредактировал(а) Akina - 26.5.2008, 12:25

Я думал над разделением диапозонов ключей, но все упиралось в "авось" при выборе стартового значения. Т.е. пересекут ли когда-нибудь ключи партнера отметку в 10000 или 100000. Столбец с владельцем интересная мысль.   
В принципе его можно обозвать как source, типа источник XML, Excel или любой другой. Надо подумать какие проблемы могут возникнуть.

Все-таки криво получается, ведь ключ должен использоваться в 4-5 таблицах, а это значит, что мне придется в каждую из них добавить еще один столбец. А в самой программе есть класс-список, метод которого получает в виде параметра ключ и возвращает ссылку на структуру. В итоге мне придется передавать не один ключ, а два.
Как-то не изящно получается и довольно сложно с этим работать. Если бы как-то сделать все-таки ключи уникальными.

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

может, лучше нормализовать?
id-у-вас, idКомпании-партнера, id-у-партнера

а если у партнера нормальное переименование, а не заторможенное? и он тоже переименовал отель в  
, а запись в файле 
 относится к новому отелю? как это отследить?
мне кажется, лучше обсудить с этими партнерами, что если они дают некорректную/устаревшую/неполную информацию, то.. ну, не знаю, в любом случае, чтоб никто не ждал "правильного" поведения потом от программы. тем более, если они не передают собственный id.

А чем тебя пугает наличие несмежных диапазонов? Выделил ты для фирмы "Вася Пупкин и Ко." диапазон 50001-60000... закончился он... ты дал им следующий доступный, скажем 150001-160000. Главное - наличие однозначного соответствия ИД-Фирма, а что блоки ИДов разорваны, ничем и никому мешать не будет. Просто сразу каждой фирме выделяется 2 блока - основной и резервный. Как кончился основной - начинается использование резервного, он соответственно становится основным, и выделяется еще один, который теперь будет резервным.


Не понял... откуда два? 

В процесс импорта входят следующие шаги:

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

В итоге имеем 6 (на деле 9) таблиц:

Отели:
ключ партнера, название
Номера:
ключ партнера, название
Размещения:
ключ партнера, название

Привязка Отелей:
ключ партнера, наш ключ
Привязка Номера:
ключ отеля партнера, ключ номера партнера, наш ключ
Привязка Размещения:
ключ отеля партнера, ключ номера партнера, ключ размещения партнера, наш ключ

Соответственно хочу как-то еще добавить возможность импортировать текстовые данные, когда ключи не известны.

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


Так ты предлагаешь вообще отказаться от использования ключей партнеров и генерить свои ?

Это сообщение отредактировал(а) SABROG - 26.5.2008, 15:17

вообще-то, да. 
при импорте обрабатывать таблицу "соответствия": скажем, у партнера 1 его илентификатор 280 транслируется  в твой "1783". а у другого "280" - в твой "785". после трансляции работаешь уже исключиться со своим id.
разве не логично? структура твоя, ключи твои. ты же кроме момента импорта со структурами партнеров не работаешь...

Дело в том, что когда уже все ключи подвязаны, то это последняя стадия, когда мои ключи нужны только для того, чтобы импортировать цены партнера в общую базу. А мне как-раз надо сделать так, чтобы процесс привязки был максимально быстрым и удобным, т.к. эта ручная работа требующая мозга человека.

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

Немного об интерфейсе. Есть некий tableview с двумя колонками, слева названия отелей партнера, справа название отелей наши. Каждый итем имеет в некотором поле DATA - ключ. Пользователь выбирает строку, где слева есть название отеля, а справа пусто (т.е. еще ничего не сопоставлено). Скажем кликает 2 раза. Программа берет ключ из поле DATA текущего итема из первой колонки и передает в качестве параметра в метод, который возвращает указатель на структуру привязок отеля. Далее мы выдаем пользователю диалог со списком отелей из нашей базы, он выбирает один. Берем указатель, который нам вернули по ключу и заполняем в нем поле Link ключем из формы, где пользователь выбрал отель, паралельно в базе данных делается UPDATE. Отсюда видно, что работать с парами ключей типа: владелец, ключ довольно сложно, т.к. большинство стандартных компонентов может содержать поля только для одного ключа. Как решение может быть передача ссылки на структуру или класс, который содержит пары ключей, только вот если структура базы данных будет меняться дальше мне придется переписывать большую часть кода.

Это сообщение отредактировал(а) SABROG - 26.5.2008, 16:16

ладно тебе. если запись в "таблице соотвествия" отсуствует, то вставляем новую. делов-то.

пусть тебе формируется список "добавленных в список названий" и ты будешь контролировать: оставить эту связь или связать с существующим уже объектом(если знаешь, что это просто переименование). 
по-другому никак. если числовые уникальные(хотя бы для партнера) ключи не передаются, то определить, что "Гена СПА" - это бывший "отель Чебурашка" можно только позвонив этому самому партнеру. так что тут без вариантов.

Во бредятина-то... Сперва набить данные, а потом их кодить...

Наоборот!!! Сперва заполняешь справочники и словари, и только после этого - раскидываешь данные. причем используя уже свои (!!!) ключи.

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

Это сообщение отредактировал(а) Akina - 26.5.2008, 18:12

Я ж грю, тут 3 проблемы возникают:

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

Но похоже придется пожертвовать всем этим, устал ломать свой мозг...

Это сообщение отредактировал(а) SABROG - 26.5.2008, 18:35

Да пожалуйста, храни в базе ключи внешней организации, кто мешает. И сверяйся с ними при импорте, если охота - и переименования вылезут, и немного импорт ускоришь (может быть). Но храни их так, именно для справки, а работать надо только со своими ключами.
Что же до скорости импорта - 2-3 минуты вряд ли станут гигантской проблемой, выгрузка скорее всего происходит раз, много два, в сутки, а то и реже... даже 5 минут - не та проблема. Впрочем, думаю, все будет быстрее. Например, импорт в Аксесс БД на 250 тыс. записей как раз с проверкой на совпадения по совокупности трех текстовых полей общей длиной в 200 байт занимает около 2 минут на гигагерцовом камне - на нормальном сервере БД все будет намного быстрее. Просто импортировать надо локальный файл, а не удаленный.