|
|
Регистрация Восстановить пароль |
Повторная активизация e-mail |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
Опции темы | Поиск в этой теме |
25.01.2018, 15:39 | #1 |
мальчик-помогай =)
Форумчанин
Регистрация: 16.09.2010
Сообщений: 522
|
Хранение большого набора чиселок. БД или что-то другое?
Доброе время суток.
Есть пары UserID-CityID. CityID, естественно, имеет всего пару сотен уникальных значений, поэтому дублирование очень сильное. Над самими данными будут выполняться только простые INSERT, DELETE и SELECT * FROM Table WHERE CityID=число. Данные приходят на сервер порциями по 0-1к UserID c общим CityID и их нужно сохранять в БД, пропуская дубликаты. Вопросы: - Стоит ли вовсе такое хранить в БД? Может есть более эффективный способ хранить CityID-список UserID. - Есть дикая мысль хранить каждый CityID в отдельной таблице. Насколько это глупая идея? Тогда бы не было дублирования. - Хотелось бы как-то эти данные делить на блоки приблизительно одного размера, но как? Уже ладно с консистентностью, ничего если кого-то нового оно пропустит или же выдаст дважды, но чтоб блоки были адекватного размера. Делать просто LIMIT по номеру блока? Сортировать данные или брать как есть? В общем, буду благодарен за любую помощь в данном вопросе. |
25.01.2018, 16:32 | #2 | |
Старожил
Регистрация: 17.11.2010
Сообщений: 18,922
|
Уникальный индекс по CityID и UserID и INSERT IGNORE или REPLACE INTO не даст создать дубликаты. Возможно и отдельные индексы по CityID и UserID для быстрой выборки
Цитата:
Если бы архитекторы строили здания так, как программисты пишут программы, то первый залетевший дятел разрушил бы цивилизацию
Последний раз редактировалось Аватар; 25.01.2018 в 16:36. |
|
25.01.2018, 16:56 | #3 |
мальчик-помогай =)
Форумчанин
Регистрация: 16.09.2010
Сообщений: 522
|
Комбинированный индекс? Не умею я их готовить, блин. Ну и всё равно CityID будет дублироваться.... не раздует базу? Хотя да, преждевременно я пытаюсь это оптимизировать т. к. пока непонятны даже объёмы данных. Может их сотни тысяч, а я тут к миллионам готовлюсь.
Вообще, есть ли вменяемая альтернатива БД для подобной задачи? Мне кажется что это неправильное использование БД т. к. тупо ведь список чисел |
25.01.2018, 17:04 | #4 |
Старожил
Регистрация: 17.11.2010
Сообщений: 18,922
|
Если в базе по любому CityID будет многократно встречаться, хоть в одной таблице, хоть вынести их список в отдельную, все равно для связки они должны быть и в другой таблице. Я бы делал в базе. Подумаешь миллион (ны) записей, это нормально )) А реляционные базы и есть списки данных, таблицы же
Если бы архитекторы строили здания так, как программисты пишут программы, то первый залетевший дятел разрушил бы цивилизацию
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Программирование или что-нибудь другое? | DedPerded | Общие вопросы по программированию, компьютерный форум | 18 | 01.08.2017 04:51 |
Indy, Synapse или что-то другое? | GreenWizard | Работа с сетью в Delphi | 8 | 08.07.2017 19:54 |
Ошибка в коде или что-то другое? | Яр|/||< (^_^) | PHP | 17 | 17.06.2010 18:10 |
preg_replace ?? или что то другое... | micron | PHP | 14 | 18.02.2010 15:10 |
Перегрев или что то другое? | AbRaKaTaBrA | Компьютерное железо | 11 | 09.02.2010 14:45 |