Data and knowledge bases

Материал из Common History development
Перейти к: навигация, поиск

Relational databases

Сетевая база с узлами

Opinions

Sergey Shishkin

Общая проблема всех табличных баз. Там хитрая теория нормализации таблиц для последующей автоматизации обработки, но в последнее время всё больше понимания в трудозатратности таких оптимизаций и ВОЗВРАЩАЮТСЯ (обратите внимание, назад к дотабличному буму, когда было только две структуры - последовательность и иерархия). Обратите внимание, если будете глубже знакомится с документацией.Там много примеров оглавления. То есть работы с иерархиями или деревьями. Скажем у нас есть параметр места, для него может быть или не быть свой тиддлер для конкретного значения, которое имеет набор конкретных значений, то есть свой список. Сейчас, например, для Декрета земле стоит значение Петроград с внешней ссылкой на статью из википедии. Но можно сделать внутреннюю, типа Смольный, которая отошлёт на тиддлер со своими параметрами, имеющими значения типа - какая-то застава, Петроград, Северо-Западная Россия, Европа ... и так далее (надо будет для примера не забытьи сделать такое ответвление!) . Каждое из который может получить свой отдельный тиддлер и так далее! Это называется сетевой базой с узлами. Они могут быть сколько угодно большими и распределенными. Почему и нужно, чтобы каждая запись (тиддер) имела свой адрес уникальный в сети. Тиддлерами можно обмениваться! И включать чужие в свои процессы! И это контролируемо и в перспективе может обрабатываться программно!

it4history

нашёл в себе смелость указать Вам, Сергей, на ошибку в ФОРМИРУЕМОЙ философии о табличных базах и дотабличному буму. Вы акцентируете внимание на ВОЗВРАЩЕНИЕ назад к дотабличному буму, когда было только две структуры последовательность и иерархия. Дело в том, что такой возврат происходит не из-за ошибочности табличных баз и объясняющей их хитрой теории нормализации таблиц, а возврат происходит диалектически с ПОЛНЫМ СОХРАНЕНИЕМ и поддтверждением правильности теории нормальных форм. То есть реляционные табличные базы данных - это стандарт и фундамент всех информационных систем. И это навсегда. Но поскольку эта наука сложная, то новичкам предлагают упрощенные понятия, как последовательность и иерархия. Вот для примера, я только что насчитал в пользовательской папке моего браузера Chrome количество баз данных SQLite. Аж 15 штук. А есть еще общие базы данных в Chrome, а есть еще базы данных не в формате SQLite. Конечно, есть исключения из правил, и для специфических задач используют не реляционные форматы хранения данных. Но поверьте, это таки исключения, а не тенденция.

Странный ответ Сергея с упоминанием грубости

Я терпеливый, но бываю даже грубым... И запомните раз и навсегда, прежде, чем рассуждать о программировании и алгоритмах при доступе к данным - изначально у вас машина тьюринга! Доступ только последовательный! Это вытекает из физической архитектуры. А вот над ним вы можете строить что угодно. И это что угодно, на уровне возможных структур формализуется вложенным списком. Нет ничего кроме вложенного списка. И как его вы реализуете используя последовательный доступ, как выстраиваете очереди, уже тема, но не касающаяся частных случаев уже по определению не физической модели представления данных, где только последовательность.