чОткий форум
Гость, Войти | Профиль | Очистить
Нов. | Избр.
Действия ...
Форумы / Программирование. Разные СУБД [закрыт для гостей] / Алгоритм - вопрос - 2. (Сообщения: 7, Страницы: 1)
20.09.2020, 01:39
    #3084
блохастые утки
блохастые утки
Гость
Скрыть профиль Поместить в игнор-лист
Алгоритм - вопрос - 2.
Имеется блок B1.
В нем лежат списки (массивы) L1, L2.
В них неважно сколько элементов.
Но в блоке места больше нет ни на что.
SmartSelect_20200920-013854_Draw.jpg
 
Рейтинг: 0 / 0
20.09.2020, 04:05
    #3087
блохастые утки
блохастые утки
Гость
Скрыть профиль Поместить в игнор-лист
Алгоритм - вопрос - 2.
(в процессе написания)
 
Рейтинг: 0 / 0
20.09.2020, 08:36
    #3091
Дырокол
Участник
Скрыть профиль Поместить в игнор-лист
Алгоритм - вопрос - 2.
автор уснул над трудом своим
 
Рейтинг: 0 / 0
25.09.2020, 18:31
    #3472
SQL
SQL
Участник
Скрыть профиль Поместить в игнор-лист
Алгоритм - вопрос - 2.
Предыдущий вопрос я немного решил, не смогя его до конца внести в учебники.
Вот был новый вопрос.
Я хочу такой тип данных в ПАШЭСУБД как SET.

Ты говоришь:
Код
1.
2.
3.
insert(K23, "sobaka");
insert(K23, "sos");
insert(K23, "sos");
И у тебя есть ключи ["sobaka", "sos"] внутри K23, а последний запрос не выполнился, потому что "sos" там уже был.
Полезная структура хранить лайки, не давай лайкнуть что-то дважды, скажем.

Ну вот. И был такой вопрос из зала: почему не сделать просто хранение двух ключей: "K23sobaka" и "K23sos", решив задачу.

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

И во-вторых я не хочу, чтобы какой-то рандомный ключ "K23s" привёл к тому, что у меня теперь в K23 как-бы уже 3 элемента.

Я хочу прямо явно, чтобы "K23s" был ключом от какого-то key=value, а "K23" был именем этого SET, т.е. key={SET} и я их отличал.
И ещё чтобы мог достаточно быстро, скажем, удалить K23, что не приводило бы к удалению огромных массивов последовательно идущих ключей, потому что нахрен надо, когда можно быстрее, скажем пометив тот K23={SET} как удалённый, что автоматически закрывает весь этот {SET} накуй.

Такие дела.

Конечно нормальный человек бы сказал: заведите K23.sos и K23.sobaka и всё. Разделяйте точкой. Введите правила генерации ключей. И не стройте вашу систему, что она может сгенерить любой другой ключ "K23.ЧТО_ТО" случайно, мол вы же не дебилы какие-то.

Ну как-бы да.

Но нормальными быть хуёво, хочется же быть рульнее. Например спросить размер всего K23 без пробега фуллсканом.

Скажем у меня лежат такие ключи:
Код
1.
2.
3.
4.
5.
6.
7.
K23.2341234
K23.asdfasdf
K23.biquhwyhedwqieojrd
K23.sos
K23.sobaka
K23.tyuiytiu
K23.zzzpzoi
И их миллион. И лежат они в 5 тыщах блоков. В каждом блоке разное их количество. Чтобы узнать размер всего поддиапазона K23, мне надо пойти и все эти блоки зафуллсканить и посчитать. А так я могу заглянуть в каждый блок, посмотреть на местный подкусочек K23, где явно написан размер и просуммировать такие. Это слегка быстрее. Или не слегка. Но скорее слегка.

Вообще конечно у нормальных СУБД есть механизмы хранения ключей с общим префиксом, который примерно работает так же как моё изобретение, поэтому подумаваю его намотать на жопу и перестать выёбываться в этом месте.
 
Рейтинг: 0 / 0
27.09.2020, 00:26
    #3519
SQL
SQL
Участник
Скрыть профиль Поместить в игнор-лист
Алгоритм - вопрос - 2.
Короче я тут кое-чё сверху этой идеи надумал.
Основное, что есть у меня - это хранение числа подключей в поддереве в виде числа в опорной ноде вверху.
Т.е. я могу хуяк глянуть на 5 чисел, сложить и получить размер, мне не надо спускаться вниз в листья и подгружать их с диска.
Более блядотого, нахуй, еббать, у могу в пагинацию.
Скажем есть SET, а ключи в нём упорядочены или не упорядочены - похуй. У меня упорядочены, скажем.
Так вот я могу сказать "дай 10 штук начиная с миллионного" и оно без фуллсканов хуяк сразу знает где искать такое смещение.
Так-то.
Нахуя это надо:

Скажем тебя лайкнул миллион человек, ты вызвал окошко списка лайкнувшик и листаешь его как пидор кармодрочер нарцисс.
А там миллион. Ясен хуй что подгружаться это будет кусками.
Вот так-то.
 
Рейтинг: 0 / 0
27.09.2020, 00:33
    #3521
SQL
SQL
Участник
Скрыть профиль Поместить в игнор-лист
Алгоритм - вопрос - 2.
Иллюстрация к пикче выше.
Мне говорят get K22["N"], значит надо пойти по среднему поинтеру, N ведь после M и до P.
А если говорят get K22[6] то доступ по индексу - 6 после последнего доступного K22-шного поинтера, где индекс 5, значит валим туда и достаём элемент "Q".

Так-то.

Ну и плюс я могу быстро размер узнать - смотрим на последний K22-шный поинтер, а там индекс 5, значит минимум 5 элементов. Валим туда и досуммируем 3 к 5, хуяк размер 8 - в K22 лежит 8 элементов.
image_2020-09-27_00-33.png
Изменено: 27.09.2020, 00:37 - SQL
Рейтинг: 0 / 0
09.09.2021, 00:11
    #4019
golem_sHTERN
Участник
Скрыть профиль Поместить в игнор-лист
Алгоритм - вопрос - 2.
отзажачи ушел посссать
 
Рейтинг: 0 / 0
Форумы / Программирование. Разные СУБД [закрыт для гостей] / Алгоритм - вопрос - 2. (Сообщения: 7, Страницы: 1)
Целевая тема:
Создать новую тему:
Автор:
Найденые участники ...
Найденые участники ...
Нов. | Избр.
x
x
Закрыть


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