Цитата:
Сообщение от Melkor
Да нет, тут не получится. Для каждого А есть много Б.
Но при этом много А могут ссылаться на одно Б.
|
тогда заголовок темы неверен. Это m*n, а не 1*n.
Цитата:
Сообщение от Melkor
На этом приходим ко второму вопросу, как эту фигню туда записать. Каждое значение в Б может встречаться во всей таблице дофига раз, но комбинация всех значений только 1.
|
Два способа:
а) искусственный ключ;
б) UNIQUE-индекс поверх всех колонок из Б.
В первом случае ты считаешь хеш от конкатенации всех полей Б и хранишь его отдельной колонкой. Делаешь индекс поверх этой колонки и при необходимости проверить, если ли определённая запись уже в это таблице, считаешь опять же хеш и ищешь хеш.
Во втором случае ты просто требуешь уникальности сочетания значений Б - и, соответственно, при поиске просто перечисляешь все эти значения.
Преимущества и недостатки, полагаю, очевидны. Первый способ даёт избыточные вычисления, но уменьшает число колонок в индексе до одной с ограниченной длиной. Если у тебя в таблице Б есть колонки типа BLOB или TEXT - то следует заюзать хеш.
Второй же способ более пригоден в случае, если у тебя в Б набор небольших данных (к примеру, несколько INTEGERов, и т.п.) - тогда расходоваться ещё и 32-байтовый хеш смысла нет, просто покрывай их все UNIQUE-индексом и ищи по сочетанию значений.
Цитата:
Сообщение от Melkor
А можно брать по несколько точек за раз и присвоить им Id. При записи искать встречается ли эта комбинация и если встречается давать ссылку на нее.
Получаем в первом случае 50 записей типа: время - значение
во втором (10 точек за раз) 5 записей типа: время - линк на таблицу значений точек.
|
Плохой пример. В данном случае лучше получить 50 записей, т.к. далее ты можешь быстрее их доставать и с ними работать. Если чтение происходит намного чаще, чем запись/обновление - то лучше пожертвовать местом в таблице и временем записи (обновления индексов) для достижения большей скорости чтения.