-Поиск по дневнику

Поиск сообщений в rss_forum_sources_ru

 -Подписка по e-mail

 

 -Постоянные читатели

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 29.07.2007
Записей:
Комментариев:
Написано: 80


Выбор типа дерева (структура данных) для хранения данных в БД

Четверг, 25 Июня 2020 г. 17:54 + в цитатник
FasterHarder: А у меня тем временем все готово! хехе

По факту получилось:
- 1300+ строк высокопроизводительного кода)
- 50+ функций, выполняющих строго одну операцию
- около 10 структур данных (очень похожих по составляющим)
----------------------------------------------------------
все прекрасно работает, интерфейс предельно дружественный и интуитивно понятный (куча подсказок и пр.).
глобальной обработки ошибок нет, так, местами есть кой какая защита
утечек в памяти не наблюдается (а там есть чему утекать, хехе)
система хорошо поддается расширению, вроде, хотя...может нет!
ход документирован, старался делать по Макконелу) (этого чувака люто уважаю и читаю его книги запоем!)
основная структура данных: двоичное дерево поиска с возможностью хранения дубликатных ключей БЕЗ балансировки

Единственное место, где мне пришлось отойти от бинарок - обработка количества пассажиров, находящихся в машине. Оно варьируется от 1 до 6. Я так чего-то прикинул, ну максимально тупо строить бинарку, хранящую всего 6 различных ключей (с дубликатами, разумеется). Если дано 90 млн. машин, у которых кол-во пассажиров равно 3 и ОДНА машина с кол-вом = 4 и эта машина (с 4мя пассажирами) добавляется последней в дерево, то все вырождается в ЛОС, при этом 4ка висит на хвосте, т е чтобы найти все машины с 4мя пассажирами пришлось бы просканировать 90млн узлов дерева. Нет уж, увольте, требования требованиями, но малейшая логика должна быть! Сделал массив списков, состоящий из 6 элементов и из каждого узла идет подписок на нужное число пассажиров. Дерево ли это? ну издалека похоже) Вообще, нет, ну, если допустить, что у узла может быть один потомок, то да)

Очень плохо, что структуры в СИ не имеют индексацию своих полей (хотя где-то видел пример через добавление указателей и чего то там мутили с объединениями, в общем я там ничего не понял и оч.рад этому) + единственная возможность в коде обращаться к ним - прописывать их название целиком.
В итоге мне нужно было строить СВОЮ отдельную бинарку для каждого поля сущности "авто", а их штук 8. При этом многие из них похожи донельзя(отличие только в названии поля). При этом ведь нужно добавить узел, сделать обход (2 способами) и удалить из памяти, минимум 4ре функции. А т к 8 полей, то РЕЗКО получаем избыточную хрень 8 * 4 = 32 функции, которые крайне похожи по обработке, но там разные поля структуры прописываются. Я хрен знает, как это шаблонизировать в си, вроде как-то делают, но я не выкупаю, да и так неплохо вышло)

Без понятия как оценить производительность работы прожки. Сравнивать не с чем. Данных нет, да и толку от них, все равно даже миллион записей не вывести на экран. Уверен, что можно все организовать эффективные в разы, используя ПРАВИЛЬНЫЕ древовидные структуры (да как бы еще знать их, века не хватит на их фундаментальное изучение), но и так все работает неплохо)

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

В общем я доволен результатом! Нет, даже ОЧЕНЬ ДОВОЛЕН!!! Пойду съем мороженку)

И самое главный императив: и тай сойдет (с) :D

https://forum.sources.ru/index.php?showtopic=419028&view=findpost&p=3833133

Метки:  

 

Добавить комментарий:
Текст комментария: смайлики

Проверка орфографии: (найти ошибки)

Прикрепить картинку:

 Переводить URL в ссылку
 Подписаться на комментарии
 Подписать картинку