Data and knowledge bases

Материал из Common History development
Версия от 09:10, 17 декабря 2018; It4history (обсуждение | вклад)
(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к навигации Перейти к поиску

Relational databases[править]

Сетевая база с узлами[править]

Opinions[править]

Sergey Shishkin[править]

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

it4history[править]

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

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

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