Guest User

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

a guest
May 6th, 2021
31
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. АНОНИМНАЯ ОПЕНСОРЦНАЯ И РЕЛЯЦИОННАЯ СУБД ИЗ ГОВНА И ПАЛОК.
  2.  
  3. Итак, грубо-говоря,
  4. любая реляционная база данных,
  5. состоит из множества таблиц,
  6. и связей между их столбцами, связей "один-к-одному" или "один-ко-многим".
  7. Связь "многие-ко-многим", реализуется через третью таблицу, связанную с другими двумя - связью "один-ко-многим".
  8. Связями "многие-ко-многим", можно взаимосвязывать любые данные, формируя любые семантические сети с "сетевой моделью данных",
  9. и в этом главная фича реляционных БД, что в них можно хранить,
  10. даже структуры нейросетей безошибочных нейроморфных и биосовместимых нанобиочипов, нейрокомпьютерных.
  11.  
  12. Данные во множестве таблиц, можно представить одной таблицей:
  13. | ID | КодТаблицы | КодСтолбца | ТипДанных | СырыеДанные |
  14.  
  15.  
  16. Пусть будет таблица:
  17. | ID | КодТаблицы | КодСтолбца | ТипДанных | СырыеДанные |
  18. | 0 | 0 | 0 | 0 | NULL |
  19. | 1 | 0 | 0 | 0 | INTEGER |
  20. | 2 | 0 | 0 | 0 | REAL |
  21. | 4 | 0 | 0 | 0 | TEXT |
  22. | 5 | 0 | 0 | 0 | BLOB |
  23. | 6 | 0 | 1 | 4 | TableName1 |
  24. | 7 | 0 | 1.1 | 4 | TableName1.FieldName1 |
  25. | 8 | 0 | 1.2 | 4 | TableName1.FieldName2 |
  26. | 9 | 0 | 1.3 | 4 | TableName1.FieldName3 |
  27. | 10 | 0 | 2 | 4 | TableName2 |
  28. | 11 | 0 | 2.1 | 4 | TableName2.FieldName1 |
  29. | 12 | 0 | 2.2 | 4 | TableName2.FieldName2 |
  30. | 13 | 0 | 2.3 | 4 | TableName2.FieldName3 |
  31. | 14 | 1 | 1 | 1 | Таблица1Столбец1Запись1.1 |
  32. | 15 | 1 | 2 | 4 | Таблица1Столбец2Запись1.Текст1 |
  33. | 16 | 1 | 3 | 5 | Таблица1Столбец2Запись1.Файл1 |
  34. | 17 | 1 | 1 | 1 | Таблица1Столбец1Запись2.2 |
  35. | 18 | 1 | 2 | 4 | Таблица1Столбец2Запись2.Текст2 |
  36. | 19 | 1 | 3 | 5 | Таблица1Столбец2Запись2.Файл |
  37. | 20 | 2 | 1 | 1 | Таблица2Столбец1Запись1.1 |
  38. | 21 | 2 | 2 | 4 | Таблица2Столбец2Запись1.Текст |
  39. | 22 | 2 | 3 | 5 | Таблица2Столбец3Запись1.Файл |
  40. | 23 | 2 | 1 | 1 | Таблица2Столбец1Запись2.2 |
  41. | 24 | 2 | 2 | 4 | Таблица2Столбец2Запись2.Текст |
  42. | 25 | 2 | 3 | 5 | Таблица2Столбец3Запись2.Файл |
  43. | 23 | 2 | 1 | 1 | Таблица2Столбец1Запись1.3 |
  44. | 24 | 2 | 2 | 4 | Таблица2Столбец2Запись2.Текст |
  45. | 25 | 2 | 3 | 5 | Таблица2Столбец3Запись2.Файл |
  46. |...|
  47.  
  48. Дальше, можно добавлять новые таблицы, и столбцы, и прочую чушь,
  49. а также ещё и данные - в различном порядке,
  50. то есть, сначала в таблицу2 записать строчку,
  51. затем в таблицу1 - ещё строчку,
  52. затем в таблицу3 - всё-равно.
  53.  
  54. Следует заметить, что строки здесь - это не строки таблицы, это ячейки в таблицах,
  55. а строчка в таблице - это последовательность ячеек, со значениями всех полей таблицы.
  56.  
  57. Столбцы в заголовке, можно двигать, в пределах одной таблицы, используя XOR-обмен их значений.
  58. Но тогда, для данных с кодом конкретной таблицы, где переставляются столбцы,
  59. надо будет произвести XOR-обмен, для кодов столбцов различных строк с данными, тоже.
  60.  
  61. Эта, одна, большая таблица одна и содержит 5 столбцов,
  62. | ID | КодТаблицы | КодСтолбца | ТипДанных | СырыеДанные |
  63. Каждая запись данных - это одна ячейка из какой-либо таблицы.
  64.  
  65. Таким образом,
  66. если
  67. реляционная база данных,
  68. содержит
  69. N таблиц с M-ю столбцами по L записей в каждой таблице,
  70. то всего ячеек: N*M*L
  71. Вот столько строк должно быть в этой, большой таблице,
  72. плюс строки заголовка,
  73. состоящего из,
  74. 5-ти типов данных (например, в SQLite - 5 типов данных, например),
  75. N таблиц, и M столбцов внутри них ( N * ( M + 1 ) записей + 5 записей - на весь заголовок ).
  76. Код таблицы, у заголовка - ноль, и заголовок, вгружается в память сразу.
  77. По пять значений, в каждой строке,
  78. итого, вот столько ячеек: ( ( 5 + N * ( M + 1 ) + N * M * L ) * 5 ).
  79.  
  80. Всё это - одна большая таблица, которая может быть вписана в двоичный файл, как файл базы в наноборде,
  81. и которая может быть проиндексирована.
  82.  
  83.  
  84. Отдельный файл-индекс, может быть выстроен для строк этой таблицы.
  85. В индексе, могут быть указаны смещения данных, различной длины, и длина их
  86. и индекс, в отличие от двоичного файла с данными,
  87. может вгружаться в память быстро, как реализовано - в наноборде.
  88. Индекс, может выглядеть так:
  89. |IDЯчейки|СмещениеНачалаДанных|ДлинаДанных|
  90. ...
  91. Ну, и, собственно - смещения данных, внутри ячеек таблицы,
  92. данных, просто содержащихся в сыром виде внутри двоичного файла...
  93.  
  94.  
  95. Можно выстроить и отдельный индекс и по двойке значений:
  96. | НомерТаблицы.НомерСтроки | IDДанныхСтолбца1.IDДанныхСтолбца2.IDДанныхСтолбца3.[...].IDДанныхСтолбцаM |
  97.  
  98. Такая таблица - имеет лишь два столбца, а комбинации уникальные - разделены точками.
  99. Почему столбца два?
  100. Да потому что если в какую-либо таблицу добавляются новые столбцы, или если старые удаляются,
  101. то проще изменить одно значение в одном столбце одной таблицы этой,
  102. а не писать ID'ы в разных столбцах, и потом их добавлять-удалять.
  103. Но походу, это надо хранить в отдельном файле, как и индексный файл.
  104.  
  105. Короче, в общем, три файла получается - двоичный файл и файл индекса, (как в наноборде),
  106. и ещё один файл, с вот этой таблицей с двумя полями,
  107. для быстрого доступа к строкам различных таблиц и получения их целиком.
  108.  
  109. Нужна она, просто, чтобы быстро возвращать всю строку по её номеру, по ID всех данных в строке,
  110. и не искать эти ID, фильтруя строчки в большой таблице - короче реализуется 2-е правило Кодда.
  111.  
  112. К тому же, если столбцы меняются местами, и если данные в соответствующих столбцах - меняются местами,
  113. то можно и здесь, XOR-обменом, изменить ид'ы столбцов.
  114.  
  115. Здесь, походу, я изобрёл и навелосипедил - констрейнт, CONSTRAINT.
  116.  
  117.  
  118. Как теперь, взаимосвязать эти таблицы?
  119. Через саму логику работы софтины, походу...
  120.  
  121.  
  122. Как извлечь данные?
  123. Либо прямо по ID, если он известен, либо по комбинации Таблица-УникальноеЗначениеПепервогоСтолбца-Столбец,
  124. поскольку значение первого столбца каждой таблицы, для каждой строки - всегда уникально.
  125. Либо строчку можно извлечь, по комбинации Таблица.НомерСтроки, по ним найти ID'ы данных соответствующих столбцов Таблицы,
  126. и извлечь эти данные в виде строчки, прямо по ID'ам.
  127.  
  128.  
  129. Как обновить данные?
  130. Для начала, надо знать и задать ячейки, то есть ID ячейки данных, и по ним найти сами данные.
  131. Дальше, сравнить, длинее ли новые данные - предыдущих данных?
  132. Если нет, и по длине равны предыдущим данным, то вписать их прямо туда, а индекс не трогать, и/или обновить длину.
  133. Если да, то создать новую запись, и вписать их туда, а также обновить оффсет и длину, в индексном файле, для этого ID.
  134. Старая запись, и данные в ней - не удаляются, а содержатся в базе данных, в виде мусора.
  135. В индексном файле, надо пометить, что эта запись удалена, но не филлить нулями сами данные, чтобы снизить нагрузку на диск,
  136. и оставить их как есть, для последующей записи туда новых данных.
  137.  
  138.  
  139. Как предотвратить рост двоичного файла базы, в случае обновления данных и вставки бОльших данных?
  140. Когда вставляются данные бОльшего размера, создаётся новая запись.
  141. Старая запись в индексе - помечается, как удалённая, но не удаляется физически (не затирается нулями).
  142. В это место, помеченное, впоследстии, можно вписать данные более короткого размера,
  143. а остаток, пометить, как свободное место, и туда ещё дописать новые ячейки данных.
  144. Таким образом, получаются разбросанные в разных местах ячейки таблицы,
  145. и база данных фрагментируется, из-за этого.
  146. Это может снизить скорость поиска, но если есть индекс, то не должно.
  147.  
  148. Как снизить фрагментацию такого файла базы данных, или произвести дефрагментацию - непонятно.
  149. Походу, тупо, его перезаписью в новый файл, а также переиндексацией, чтобы записи в индексе тоже, шли по порядку.
  150.  
  151. Как прикрутить сюда SQL?
  152. А надо пирдолицца с этим - неибацца как, но скажу сразу, что так, шо яибу ваще нах.
  153. ХЗ, соответствует ли это всё всем 12-ти правилам Кодда, ну а насчет ACID-транзакций, так то ваще пездос.
  154. Однако, всё это, уже - на уровне самой логики софтины, можно замутить, походу.
  155.  
  156. Здесь же, как-бэ, решается задача того, чтобы сохранить ебическую кучу таблиц,
  157. в оптимальной, так-сказать, универсальной, унифицированной и стандартизированной форме - то есть,
  158. в виде слегка модифицированной god_table: http://arhivach.net/thread/686908/#1905932
  159.  
RAW Paste Data