Программирование своей БД. Чтения/запись БД несколькими юзерами. (Си)

_basmp_

понятно.
можно использовать для того, чтобы изменённую запись "прожурналировать", т.е. сохранить новые данные и датавремя изменения данных записи (хранить несколько записей с одним уникальным ключом, и выбирать по датавремя). если конечно вместо int полные 8 байтов выделить.

 

Советую почитать про устройство Ubuntu

 

мы такое устройство не выпускаем )

 

Но интересна сама структура обращения к БД

 

Rel

читаем/изменяем в середине. что будет с линейным индексом?

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

t00x

формат записи чисел я предполагаю не фиксированый. но пока о нем не речь. тут каждый сможет извратиться как ему. те макс - конечно 64б или даже 128б или еще больше. щас вопрос какие еще элементы включить, исключить и зачем. те формат + связаный с ним протокол.

а возможность лепить если надо историю (субверсии) - это интересно. не думал об этом.

 

_basmp_

наиболее часто в каждой записи меняется одно или несколько полей, что при большом размере записи будет съедать много места; а в некоторых базах данных содержимое вообще может не изменяться (никогда).
в целях экономии места целесообразнее будет сделать эту возможность настраиваемой для каждого отдельного файла базы данных.

 

t00x

ну можно субверсить/альтернатить и неполные группы полей. если понять как это сделать нормально, то включится и мысль Rel, но только не в плане разных полей, а в плане возможности урезаных наборов полей.
в таком случае запись/альтернатива получит еще байт флагов для различения вариантов записи и по длине + номеру к каждому полю. лучше всего в тэговом не фиксированом стиле наподобие устройства свф.

 

чет я уже потерял ход нашей мысли))))

 

Rel

_basmp_
нет, никаких компромиссов в прозрачности архитектуры.
при создании таблицы указывать с таким полем таблица или без. концептуально похоже на автоинкрементное поле, только это поле ДАТАВРЕМЯ.

 

Rel
все просто. в заголовке прописан полный список полей.
одной из характеристик поля является его номер или индекс если хотите. в записи поля будут идти в виде тегов, те каждое будет предваряться его индексом по списку в заголовке и полным размером.
такой подход позволит хранить/изменять не полными наборами полей, а также добавлять/удалять(?) поля в уже существующих таблицах.
ну, а с флагами значения записи в цепочках можно будет легко различить как конкурентные, версионные (вот вам и восстановление после удаления. просто возвратим старую версию) или просто дозапись ранее не существовавших полей.
причем, в случае дозаписи и возникновении нескольких тегов с одним индексом действующим будет считаться из более поздней записи.

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

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

 

ну да... вполне нормально...

вообще я предлагаю перенести тему в другой раздел (очевидно в прожектс), а то здесь она оффтопит))))

 

ну и что? надоело уже?

 

так я хз... чет никто не пишет))))

 

- предлалаю также сливать лежащие рядом незанятые пространства в одно, а при выделении разбивать. как это делается в хип менеджерах. (вроде писал)
- кроме того, при объемах таблицы больше определенного предлагаю добавлять хэштаблицу для быстрого поиска
- и еще, всю внутреннюю структуру предлагаю забазировать на тэгах, тк они исключительно удобны

 

да я думаю, хеш-таблицу можно создавать с самого начала...

так примерно это я и предлагал делать в начале))))

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

 

- 32-битный без знака надо вместо

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

 

Rel

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

вначале этого делать не стоит, тк это достаточно непросто. это взгляд в будущее

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

все компоненты хидера - тоже оформить как тэги. это решит вопрос с версиями и субверсиями самой базы

 

Я так понимаю дальше обсуждений процесс не пошел? или как?

 

лично у меня щас времени нету, занят очень. за остальных - не знаю. знаю только, что если писать буду один, то не в опенсорс. не один - возможны варианты

 

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