Результаты поиска

Задать вопрос
Найдено результатов: 6

Изучение основ программирования (алгоритмы, структуры данных...)

Я работаю программистом (.NET WPF), но чувствую, что мне часто не хватает знаний основ программирования (основные алгоритмы, структуры данных, итп), те вещи, которые люди обычно изучают в вузах. Моя специальность была не программирование, поэтому ничего из этого мы не изучали. Хотелось бы самостоятельно восполнить эти пробелы.

Какие материалы вы посоветуете для изучения? Сайты, книги, сайты с задачками и.т.п.

p.s. (О существовании труда Д. Кнута я конечно-же знаю, что еще помимо него? :)



Организация хранения структуры категорий в реляционной БД?

Задача — организовать хранение некоего каталога, с достаточно разветвлённой структурой (дерево) — пускай это будет каталог продукции интернет-магазина. Для поиска элемента доступен только URI вида "/category/subcategory/another-category/and-one-more-category". Максимальная вложенность порядка 10.


Категории запрашиваются часто, меняются редко, общее количество категорий может быть порядка 100 тыс.


Так же требуется шустрая генерация «хлебных крошек». Причём ссылка на категорию («and-one-more-category») может отличаться от её заголовка («И ещё одна категория»), который используется для вывода на странице.


У меня пока одно предполагаемое решение — «в лоб» — по следам Materialized path:

таблица для категорий имеет следующую структуру


CREATE TABLE categories (

`id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY,

`title` VARCHAR(50) NOT NULL,

`link` VARCHAR(50) NOT NULL,

`path` VARCHAR(1000) NOT NULL,

`title_path` VARCHAR(1000) NOT NULL

)


CREATE INDEX path_indx ON categories (`path`);


`title` — заголовок категории («И ещё одна категория»),

`link` — ссылка категории («and-one-more-category»),

`path` — путь к категории («category/subcategory/another-category/and-one-more-category»),

`title_path` — то же, что и `path`, только содержит заголовки соответствующих категорий — для быстрой генерации «хлебных крошек»


— Привлекает то, что для поиска категории не нужно никаких усилий — просто SELECT… WHERE path LIKE…

— Не пугает даже необходимость перестроения путей в случае перемещения/переименования узлов.

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

— Так же смущает то, что в качестве ключа для поиска используется такая длинная строка в `path` (хотя я очень сомневаюсь что она когда-либо выйдет за пределы 100 символов)


Может вынести `path` и `title_path` в отдельную таблицу? Так всё равно путь и хлебные крошки для категории требуется практически всегда, так что придётся джойнить…


Смотрю в сторону Full hierarchy, но опять же смущает возможная избыточность в таблице иерархии, тем более учитывая потенциальные количества категорий и уровни вложенности.


Как более оптимально решить задачу?

SQL   Базы   данных   Иерархические   структуры    

379   4   16:08, 9th August, 2020


Разделять ли содержимое объекта и данные по его расположению в иерархии?

Звучит наверное не совсем понятно, поэтому поясню:

Пусть у нас есть дерево комментариев (Nested Sets или еще что-то, в принципе не важно). Стоит ли выносить поля, не относящиеся напрямую к комментариям (lft, rgt, parent_id и т.д.) в отдельную таблицу БД? С одной стороны, мы избавляемся от привязки к конкретной структуре комментариев (всегда можно поменять NS на MP или еще что-то), а с другой — появляются сложности с объединением этих таблиц.



Функциональная структура суперВС Jaguar

Нужна информация по функциональной структуре машины Jaguar (http://top500.org/system/details/10184), которая сейчас занимает второе место по производительности в списке ТОП 500.

Структуры   данных    

303   2   14:33, 8th August, 2020


Структуры данных Sphinx & Lucene

Добрый день.
Не поделится ли кто сокровенным знанием? :)
Нужны структуры данных индексных файлов поисковиков Sphinx, Lucene. Если есть аналогичная информация по другим — тоже не откажусь, если движок достаточно шустрый. Поставленная перед собой задача — понять механизм наполнения поисковых баз и поиска по ним. Хотелось бы избежать нудного и неблагодарного кодокопательства.
Общая файловая структура Lucene описывается, но очень общая, хотелось бы поподробней.



Формализованное описание структур данных — как?

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


Для каждой разновидности структур данных человечество уже придумало множество способов формализованного описания конкретной модели данных, начиная от XML-схемы и SQL DDL, и заканчивая JSON. Однако, как математически определить саму структуру так, чтобы это было грамотно и понятно читателю — решительно непонятно. Как показать, что данные будут организованы в стек или красно-черное дерево, кроме того, что написать эти термины или нарисовать картинку?


Буду благодарен за любые идеи или наводки, где подобные описания используются.