АНОНИМНАЯ ОПЕНСОРЦНАЯ И РЕЛЯЦИОННАЯ СУБД ИЗ ГОВНА И ПАЛОК

АНОНИМНАЯ ОПЕНСОРЦНАЯ И РЕЛЯЦИОННАЯ СУБД ИЗ ГОВНА И ПАЛОК.

Итак, грубо-говоря,
любая реляционная база данных,
состоит из множества таблиц,
и связей между их столбцами, связей "один-к-одному" или "один-ко-многим".
Связь "многие-ко-многим", реализуется через третью таблицу, связанную с другими двумя - связью "один-ко-многим".
Связями "многие-ко-многим", можно взаимосвязывать любые данные, формируя любые семантические сети с "сетевой моделью данных",
и в этом главная фича реляционных БД, что в них можно хранить,
даже структуры нейросетей безошибочных нейроморфных и биосовместимых нанобиочипов, нейрокомпьютерных.

Данные во множестве таблиц, можно представить одной таблицей:
|	ID	|	КодТаблицы	|	КодСтолбца	|	ТипДанных	|	СырыеДанные						|


Пусть будет таблица:
|	ID	|	КодТаблицы	|	КодСтолбца	|	ТипДанных	|	СырыеДанные						|
|	0	|	0			|	0			|	0			|	NULL							|
|	1	|	0			|	0			|	0			|	INTEGER							|
|	2	|	0			|	0			|	0			|	REAL							|
|	4	|	0			|	0			|	0			|	TEXT							|
|	5	|	0			|	0			|	0			|	BLOB							|
|	6	|	0			|	1			|	4			|	TableName1						|
|	7	|	0			|	1.1			|	4			|	TableName1.FieldName1			|
|	8	|	0			|	1.2			|	4			|	TableName1.FieldName2			|
|	9	|	0			|	1.3			|	4			|	TableName1.FieldName3			|
|	10	|	0			|	2			|	4			|	TableName2						|
|	11	|	0			|	2.1			|	4			|	TableName2.FieldName1			|
|	12	|	0			|	2.2			|	4			|	TableName2.FieldName2			|
|	13	|	0			|	2.3			|	4			|	TableName2.FieldName3			|
|	14	|	1			|	1			|	1			|	Таблица1Столбец1Запись1.1		|
|	15	|	1			|	2			|	4			|	Таблица1Столбец2Запись1.Текст1	|
|	16	|	1			|	3			|	5			|	Таблица1Столбец2Запись1.Файл1	|
|	17	|	1			|	1			|	1			|	Таблица1Столбец1Запись2.2		|
|	18	|	1			|	2			|	4			|	Таблица1Столбец2Запись2.Текст2	|
|	19	|	1			|	3			|	5			|	Таблица1Столбец2Запись2.Файл	|
|	20	|	2			|	1			|	1			|	Таблица2Столбец1Запись1.1		|
|	21	|	2			|	2			|	4			|	Таблица2Столбец2Запись1.Текст	|
|	22	|	2			|	3			|	5			|	Таблица2Столбец3Запись1.Файл	|
|	23	|	2			|	1			|	1			|	Таблица2Столбец1Запись2.2		|
|	24	|	2			|	2			|	4			|	Таблица2Столбец2Запись2.Текст	|
|	25	|	2			|	3			|	5			|	Таблица2Столбец3Запись2.Файл	|
|	23	|	2			|	1			|	1			|	Таблица2Столбец1Запись1.3		|
|	24	|	2			|	2			|	4			|	Таблица2Столбец2Запись2.Текст	|
|	25	|	2			|	3			|	5			|	Таблица2Столбец3Запись2.Файл	|
|...|

Дальше, можно добавлять новые таблицы, и столбцы, и прочую чушь,
а также ещё и данные - в различном порядке,
то есть, сначала в таблицу2 записать строчку,
затем в таблицу1 - ещё строчку,
затем в таблицу3 - всё-равно.

Следует заметить, что строки здесь - это не строки таблицы, это ячейки в таблицах,
а строчка в таблице - это последовательность ячеек, со значениями всех полей таблицы.

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

Эта, одна, большая таблица одна и содержит 5 столбцов,
|	ID	|	КодТаблицы	|	КодСтолбца	|	ТипДанных	|	СырыеДанные					|
Каждая запись данных - это одна ячейка из какой-либо таблицы.

Таким образом,
если
реляционная база данных,
содержит
N таблиц с M-ю столбцами по L записей в каждой таблице,
то всего ячеек: N*M*L
Вот столько строк должно быть в этой, большой таблице,
плюс строки заголовка,
состоящего из,
5-ти типов данных (например, в SQLite - 5 типов данных, например),
N таблиц, и M столбцов внутри них ( N * ( M + 1 ) записей + 5 записей - на весь заголовок ).
Код таблицы, у заголовка - ноль, и заголовок, вгружается в память сразу.
По пять значений, в каждой строке,
итого, вот столько ячеек: ( ( 5 + N * ( M + 1 ) + N * M * L ) * 5 ).

Всё это - одна большая таблица, которая может быть вписана в двоичный файл, как файл базы в наноборде,
и которая может быть проиндексирована.


Отдельный файл-индекс, может быть выстроен для строк этой таблицы.
В индексе, могут быть указаны смещения данных, различной длины, и длина их
и индекс, в отличие от двоичного файла с данными,
может вгружаться в память быстро, как реализовано - в наноборде.
Индекс, может выглядеть так:
|IDЯчейки|СмещениеНачалаДанных|ДлинаДанных|
...
Ну, и, собственно - смещения данных, внутри ячеек таблицы,
данных, просто содержащихся в сыром виде внутри двоичного файла...


Можно выстроить и отдельный индекс и по двойке значений:
|	НомерТаблицы.НомерСтроки	|	IDДанныхСтолбца1.IDДанныхСтолбца2.IDДанныхСтолбца3.[...].IDДанныхСтолбцаM	|

Такая таблица - имеет лишь два столбца, а комбинации уникальные - разделены точками.
Почему столбца два?
Да потому что если в какую-либо таблицу добавляются новые столбцы, или если старые удаляются,
то проще изменить одно значение в одном столбце одной таблицы этой,
а не писать ID'ы в разных столбцах, и потом их добавлять-удалять.
Но походу, это надо хранить в отдельном файле, как и индексный файл.

Короче, в общем, три файла получается - двоичный файл и файл индекса, (как в наноборде),
и ещё один файл, с вот этой таблицей с двумя полями,
для быстрого доступа к строкам различных таблиц и получения их целиком.

Нужна она, просто, чтобы быстро возвращать всю строку по её номеру, по ID всех данных в строке,
и не искать эти ID, фильтруя строчки в большой таблице - короче реализуется 2-е правило Кодда.

К тому же, если столбцы меняются местами, и если данные в соответствующих столбцах - меняются местами,
то можно и здесь, XOR-обменом, изменить ид'ы столбцов.

Здесь, походу, я изобрёл и навелосипедил - констрейнт, CONSTRAINT.


Как теперь, взаимосвязать эти таблицы?
Через саму логику работы софтины, походу...


Как извлечь данные?
Либо прямо по ID, если он известен, либо по комбинации Таблица-УникальноеЗначениеПепервогоСтолбца-Столбец,
поскольку значение первого столбца каждой таблицы, для каждой строки - всегда уникально.
Либо строчку можно извлечь, по комбинации Таблица.НомерСтроки, по ним найти ID'ы данных соответствующих столбцов Таблицы,
и извлечь эти данные в виде строчки, прямо по ID'ам.


Как обновить данные?
Для начала, надо знать и задать ячейки, то есть ID ячейки данных, и по ним найти сами данные.
Дальше, сравнить, длинее ли новые данные - предыдущих данных?
	Если нет, и по длине равны предыдущим данным, то вписать их прямо туда, а индекс не трогать, и/или обновить длину.
	Если да, то создать новую запись, и вписать их туда, а также обновить оффсет и длину, в индексном файле, для этого ID.
	Старая запись, и данные в ней - не удаляются, а содержатся в базе данных, в виде мусора.
	В индексном файле, надо пометить, что эта запись удалена, но не филлить нулями сами данные, чтобы снизить нагрузку на диск,
	и оставить их как есть, для последующей записи туда новых данных.


Как предотвратить рост двоичного файла базы, в случае обновления данных и вставки бОльших данных?
Когда вставляются данные бОльшего размера, создаётся новая запись.
Старая запись в индексе - помечается, как удалённая, но не удаляется физически (не затирается нулями).
В это место, помеченное, впоследстии, можно вписать данные более короткого размера,
а остаток, пометить, как свободное место, и туда ещё дописать новые ячейки данных.
Таким образом, получаются разбросанные в разных местах ячейки таблицы,
и база данных фрагментируется, из-за этого.
Это может снизить скорость поиска, но если есть индекс, то не должно.

Как снизить фрагментацию такого файла базы данных, или произвести дефрагментацию - непонятно.
Походу, тупо, его перезаписью в новый файл, а также переиндексацией, чтобы записи в индексе тоже, шли по порядку.

Как прикрутить сюда SQL?
А надо пирдолицца с этим - неибацца как, но скажу сразу, что так, шо яибу ваще нах.
ХЗ, соответствует ли это всё всем 12-ти правилам Кодда, ну а насчет ACID-транзакций, так то ваще пездос.
Однако, всё это, уже - на уровне самой логики софтины, можно замутить, походу.

Здесь же, как-бэ, решается задача того, чтобы сохранить ебическую кучу таблиц,
в оптимальной, так-сказать, универсальной, унифицированной и стандартизированной форме - то есть,
в виде слегка модифицированной god_table: http://arhivach.net/thread/686908/#1905932