Основы работы с БД

[shade]

о мысли сходятся =)

Ну дык решение почти очевидное =)

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

Тогда так: каждое задание (как набор вопросов) сохраняется в файле некоторого формата (например, XML, INI или мб что-то свое), который шифруется. Клиент скачивает задание, хоть через флоппинет... Программа распаковывает файл в памяти, проводит экзаменовку. Получает ответы, ответы шифруются и записываются в файл. Отсылаются на проверку. Если работа online не подразумевается, то распространение результатов по любому выходит за рамки программы... можно просто формировать отчет в виде HTML-файла, который выложить на веб-сервере или распечатать или повесить где-нибудь.

Если бы строки на разработку были жесткими, то я бы не стал возиться с XML и БД и все быстренько накодил бы ручками.

[Troublemaker]

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

Meine Gott im Himmel!
Структура входящего пакета (кратко):

КОЛЛЕКЦИЯ: состоит из модулей двух типов (могут присутствовать как оба типа одновременно, так и любой из них)
МОДУЛЬ: набор теории для изучения, набор данных для проверки знаний
МОДУЛЬ-ТЕОРИЯ: произвольная информация, например, в HTML
МОДУЛЬ-ПРОВЕРКА: перечень вопросов разного типа (выбрать один из предложенных вариантов, выбрать несколько из предложенных, вписать правильный, другие варианты) и варианты ответов на них (для варианта "вписать правильный" ответы не предусматриваются)
ОТВЕТЫ: готовые (один или несколько - в зависимости от типа вопроса - правильный, остальные неправильные) и сгенерированные (например, автосоздание неправильных ответов или расчет правильного ответа для вычислительных вопросов).

Кроме того, в каждом блоке (коллекция, модуль, вопрос, ответ) хранится и дополнительная служебная информация, так же перечисленная (частично) в ПЗ.

Ну и что для организации подобной структуры подходит лучше реляционной БД?

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

Сразу вспоминается бородатое:
- Боец!
- Я!
- Бери лом и подметай плац!
- Есть, товпрапор! Но... Но ведь ломом неудобно?
- А мне не надо, чтобы тебе было удобно, мне надо, чтобы ты зае...лся!

Согласись, что хранить картинки в XML - занятие не самое приятное, ибо текстовым форматом не предусмотрено хранение двоичной информации. Значит надо использовать что-то вроде UUE. UUE (за base64 и другие способы MIME-кодирования не скажу ничего) увеличивает объем данных примерно в полтора раза.
Для чего картинки и вообще двоичка? См. выше - вопросы могут быть РАЗНОГО типа - от пресловутой текстовой строчки "Сколько букв в слове "Attid"?" до набора картинок с УГО для принципиальных схем, которые нужно расположить в правильном порядке, чтобы получилась схема мультивибратора с положительной обратной связью.
Значит картинки лучше хранить в блобах - как МНЕ известно, блобы, в отличие от мемо, не обладают фиксированным размером, а занимают столько, сколько необходимо для хранения содержимого плюс небольшой оверхед.

Если я не прав в своих рассуждениях, то прошу указать, где и именно, и поправить меня.

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

А-а-а!!! Ну а я о чем говорю? Посмотри, пожалуйста, ближе к началу треда - именно это я и собираюсь сделать!

[alexs]

В чём вобще проблема? тут тебе столько решений уже предложили. Выбирай любое.
Задачка то тривиальная!

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

Гнилая отмазка
Ты этож не руками обрабатывать будеш - уже давно всё реализовано.

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

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

Придумай свой формат пакета - где будет и текст и бинарное идти в перемешку в одном файле (если тебя xml не устраивает).

[Troublemaker]

Ты этож не руками обрабатывать будеш - уже давно всё реализовано.

Размеры, сударь, размеры! Я не сказал, что хранить картинки в XML нельзя, я сказал - что это не самая лучшая мысль.

Придумай свой формат пакета - где будет и текст и бинарное идти в перемешку в одном файле (если тебя xml не устраивает).

Ребята, без обид - иногда наш разговор напоминает общение с программой типа megahal или Lisa, ну, имитатор ИИ: его памяти хватает только на последнюю реплику, предпоследнюю он уже не помнит.

Я:
данные для передачи буду хранить в том формате, в каком сочту нужным, это не вопрос
Мне:
придумай свой формат пакета
Я:
задания будут идти одним файлом
Мне:
задание как набор вопросов пусть сохраняется в файле
Я (несколько раз подряд):
структура такая: четыре связанных таблицы, хранятся в ОПЕРАТИВКЕ во время работы
Мне-1:
Используй такую-то СУБД
Мне-2:
Зачем тебе четыре таблицы?
Мне-3:
используй такой-то ФАЙЛОВЫЙ формат
Мне-4:
БД тебе не нужна

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

[alexs]

Ребята, без обид - иногда наш разговор напоминает общение с программой типа megahal или Lisa, ну, имитатор ИИ: его памяти хватает только на последнюю реплику, предпоследнюю он уже не помнит.

Воистину так
очень часто ответ может быть построен по последним сообщениям. Каждый раз нет возможность перечить весь топик. Когда идёт конструктивное обсуждени - это нормально. А когда как здесь - то получаются метания.
Ты, как инициатор топика и прямо заинтересованное лицо, задавай конкретные вопросы и направляй обсуждение в нужуну тебе сторону. Тогда будет всё нормально.

[Troublemaker]

задавай конкретные вопросы и направляй обсуждение в нужуну тебе сторону

Пытаюсь. Но с переменным успехом.

Так вот, у меня сейчас есть две основные задачи:

1. хранить все данные для работы в оперативке - думаю, потратить несколько мегов ОЗУ на современных и не очень компах не самая большая проблема.

2. отображать эти данные в нужном мне виде.

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

Для хранения данных снаружи я буду использовать что-нибудь, что именно - несущественно. Сейчас пытаюсь понять, что же это за пары "name=value" в TStrings с потомками и как организовать горизонтальную прокрутку листбокса - я не вижу у него свойства, отвечающего за скроллбары.
Если n=v - то, что я думаю, то бишь то самое подобие ini-файла, пусть даже и без секций, то мне оно подходит почти идеально: читаю кодированные строки из файла в TStrings/Tstringlist, декодирую и использую. Проблему с картинками в блобах отложу на время.

Вот сейчас и думаю: какой же вариант предпочтительней - продолжать возиться с memdataset (как тогда быть, если мне нужны эти чертовы четыре таблицы?) или сразу переключиться на списки строк?

[Attid]

Meine Gott im Himmel!
Структура входящего пакета (кратко):

не вижу для чего это все связывать, ИМХО это разные вещи, а котлеты с мухами как известно не стоит мешать.

Воистину так
очень часто ответ может быть построен по последним сообщениям. Каждый раз нет возможность перечить весь топик. Когда идёт конструктивное обсуждени - это нормально. А когда как здесь - то получаются метания.
Ты, как инициатор топика и прямо заинтересованное лицо, задавай конкретные вопросы и направляй обсуждение в нужуну тебе сторону. Тогда будет всё нормально.

+1 надо добивать один вопрос. потом браться за другой.

но все равно 4 датасета это не БД, БД это птиц или скллайт, третьего не дано.

продолжать возиться с memdataset

он тоже не БД. он может держать одну таблицу, ты их можешь сделать 10 штук, будет 10 таблиц, но не будет связей.

Если n=v - то, что я думаю, то бишь то самое подобие ini-файла, пусть даже и без секций,

все-таки глянь на datafile там и секции будут и картинки

[Troublemaker]

е вижу для чего это все связывать, ИМХО это разные вещи

Не разные. Попробую изобразить (схема очень упрощенная, претензии типа "а на фига такие скудные типы?" не примаются - это СХЕМА, а не детальное описание):

collection:record of
ID:byte
Desc:String
data:record of
...
end

block:record of
ID:byte
parent_coll_ID:byte
data:record of
...
end

question:record of
ID:byte
parent_block_ID:byte
data:record of
...
end

answer:record of
ID:byte
parent_question_ID:byte
data:record of
...
end

То есть, получаются четыре таблицы, в каждой из которых данные одного типа (не будем пока о внутреннем устройстве этих типов), связанные друг с другом цепочкой по полю parent_..._ID соотношением (сверху вниз) 1:М. Классическая реляционная БД в самом каноническом виде.

4 датасета это не БД, БД это птиц или скллайт, третьего не дано

Ошибашшся! Давай не будем путать БАЗУ данных и СИСТЕМУ УПРАВЛЕНИЯ базами данных?

может держать одну таблицу, ты их можешь сделать 10 штук, будет 10 таблиц, но не будет связей.

Вот об этом, кстати, я тоже спрашивал не так давно - "что есть датасет вообще и мемдатасет в частности".

все-таки глянь на datafile

Это кто и где? Я что-то пропустил? Оно может размещаться целиком в оперативке?

[shade]

1. Если нужно зашифровать БД, то sqlite, firebird не пойдут
2. писать свой dataset я не вижу смысла.
3. если тебе нужно хранить и картинки, то ini-файлы тоже не лучшее решение

Ты расписал схему, все что-то теперь нужно так это создать соответствующие типы реализующие необходимую структуру данных. Я бы, наверное, написал класс который будет хранить всю эту информацию. В нем было два метода LoadToStream, SaveToStream, которые принимают поток. Шифрование/дешифрование реализовал бы также в виде класса потомка TStream.

Можно предложить сделать так: каждый описаный тобой record делаешь соответствующий класс. В каждом реализуешь методы SaveToStream/LoadToStream, на каждый тип создаешь класс-список, который инкапсулирует TList или может быть TCollection. Каждый такой список хранит соответствующие объекты. В них также делаешь методы LoadFromStream/SaveToStream с примерно такой реализацией

Код: Выделить всё

procedure TBlocksList.SaveToStream(stream: TStream);
var i, len: Integer;
begin
  len := count;
  Stream.writebuffer(len, sizeof(len));
  for i := 0 to len-1 do
  begin
    Item[i].SaveToStream(stream);
  end;
end;
procedure TBlocksList.LoadToStream(stream: TStream);
var i, len: Integer;
begin
  Stream.readbuffer(len, sizeof(len));
  count := len; // здесь должны создаться недостающие объекты и удалиться лишние
  for i := 0 to len-1 do
  begin
    Item[i].LoadToStream(stream);
  end;
end;


Делаем класс TMyDB в который инкапсулирует эти списки и опять же делаешь методы LoadFromStream/SaveToStream;

Код: Выделить всё

procedure TMyDB.SaveToStream(stream: TStream);
begin
  collection.SaveToStream(stream);
  questions.SaveToStream(stream);
  blocks.SaveToStream(stream);
  answer.SaveToStream(stream);
end;

procedure TMyDB.LoadFromStream(stream: TStream);
begin
  collection.LoadFromStream(stream);
  questions.LoadFromStream(stream);
  blocks.LoadFromStream(stream);
  answer.LoadFromStream(stream);
end;


Перед началом тестирования все загружаешь MyDB.LoadFromStream(CrypetedStream), после оконачания сохраняешь MyDB.SaveToStream(CrypetedStream)

Всё это дело называется серализацией/десериализацией. SaveToStream() сериализует объект, LoadFromStream() десериализует. Здесь нам нужна не БД, а файлы: входной файл - задание (вопросы), выходной файл - результата (ответы). Потому бы я сделал два класса TProblem (задание) и TResult (результат). Перед началом тестирования десериализуется задание: AProblem.LoadFromStream(CryptedStream); после тестирования сериализуется ответы: AResult.SaveToSteam(CrypetedStream).

На сервере
1. для редактирования сериализуем/десериализуме TProblem.
2. для проверки десериазуем TProblem, потом по очереди десериализуем ответы (TResult) каждого испытуемого, проверяем, оценку записываем в очет, можно в обычную БД.

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

Вопрос том, нужна ли БД зависит от того, что планируется делать с результатми испытаний. Если нужна статистика, то возможно стоит использовать БД, хотя можно обойтись и без неё сделав всё также на файлах. Если с резульатами испытаний ничего более, кроме как проверить и выставить оценки, делать не нужно, то и БД не нужна.

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

[Troublemaker]

shadeСпасибо за вразумительные и полезные объяснения. Примерно так я и собираюсь делать, хотя идея насчет SaveMyDB (ну и т.д.) мне в голову не приходила.
Если можно, не отказался бы увидеть пример класса-списка - приблизительно представляю, как оно может быть, но только приблизительно.

Насчет "нужна или нет БД" см. мой предыдущий ответ Attid-у: БД и СУБД - разные вещи, и я стараюсь не смешивать два этих понятия. SQlite, FB и т.п. - это СУБД, а создаваемые ими файлы - это файлы, в которых хранится БД.

К своему стыду должен признаться, что до сих пор не понимаю разницы в паскале между class и object. Оба имеют методы и свойства, а в чем различия?

[shade]

Код: Выделить всё

unit blocks;

{$ifdef fpc}
{$mode objfpc}
{$longstrings on}
{$endif}

interface
uses Classes;

type
  TBlock = class // а может record или object ?
    // для примера:
    public
      some_id: Integer;
      some_str: string;
      procedure SaveToStream(stream: TStream);
      procedure LoadFromStream(stream: TStream);
  end;
 
  TBlocksList = class
    private // можно protected
      FList: TList;
    protected
      function GetCount: Integer;
      procedure SetCount(NewCount: Integer);
      function GetItem(idx: Integer): TBlock;
      procedure SetItem(idx: Integer; ABlock: TBlock);
    public
      constructor Create;
      destructor Destroy; override; // RTFM
     
      procedure SaveToStream(stream: TStream);
      procedure LoadFromStream(stream: TStream);
     
      // можно также добавить по вкусу методы
      // procedure Add(Block: TBlock);
      // procedure Delete(Idx: Integer);
      // function IndexOf(Block: TBlock);
      // и т.п.
     
      property Count: Integer read GetCount write SetCount;
      property Items[idx: Integer]: TBlock read GetItem write SetItem; default;
    end;

implementation

procedure write_string_to_stream(stream: TStream; const S: string);
var len: integer;
begin
  len := length(S);
  stream.WriteBuffer(len, sizeof(len));
  stream.WriteBuffer(S[1], len);
end;

function read_string_from_stream(stream: TStream): string;
var len: integer;
begin
  stream.ReadBuffer(len, sizeof(len));
  SetLength(Result, len);
  stream.ReadBuffer(Result[1], len);
end;

procedure TBlock.SaveToStream(stream: TStream);
begin
  stream.WriteBuffer(some_id, sizeof(some_id));
  write_string_to_stream(stream, some_str);
end;

procedure TBlock.LoadFromStream(stream: TStream);
begin
  stream.ReadBuffer(some_id, sizeof(some_id));
  some_str := read_string_from_stream(stream);
end;

constructor TBlocksList.Create;
begin
  inherited Create;
  FList := TList.Create; // создаем список
end;

destructor TBlocksList.Destroy;
begin
  FList.Free; // Free!, not Destroy
  inherited Destroy;
end;

function TBlocksList.GetCount: Integer;
begin
  // все просто
  Result := FList.Count;
end;

procedure TBlocksList.SetCount(NewCount: Integer);
var i, OldCount: Integer;
begin
  // чуть сложнее
  OldCount := FList.Count;
  if OldCount = NewCount then Exit;
  if OldCount > NewCount then
  begin
    // список уменьшается, удалим лишние объекты
    for i := NewCount to OldCount-1 do
      TBlock(FList[i]).Free;
  end; // if
  FList.Count := NewCount;
  if OldCount < NewCount then
  begin
    // список расширяется, создадим недостающие объекты
    for i := OldCount to NewCount-1 do
      FList[i] := TBlock.Create;
  end; // if
end;

function TBlocksList.GetItem(Idx: Integer): TBlock;
begin
  Result := TBlock(FList[Idx]);
end;

procedure TBlocksList.SetItem(idx: Integer; ABlock: TBlock);
begin
  FList[Idx] := ABlock;
end;

procedure  TBlocksList.SaveToStream(stream: TStream);
var i, len: Integer;
begin
  len := FList.Count;
  stream.WriteBuffer(len, sizeof(len));
  for i := 0 to len-1 do
  begin
    TBlock(FList[i]).SaveToStream(stream);
  end; // for i
end;

procedure TBlocksList.LoadFromStream(stream: TStream);
var i, len: integer;
begin
  stream.ReadBuffer(len, sizeof(len));
  Count := len;
  for i := 0 to len-1 do
  begin
    TBlock(FList[i]).LoadFromStream(stream);
  end; // for i
end;

end.

Код: Выделить всё

{$ifdef fpc}
{$mode objfpc}
{$longstrings on}
{$endif}

uses SysUtils, Classes, blocks;

var
  BlocksList: TBlocksList;
  fs: TFileStream;
  i, Len: integer;

begin
  BlocksList := TBlocksList.Create;
  try
    BlocksList.Count := 2;
   
    with BlocksList[0] do
    begin
      some_id := 1;
      some_str := 'Hello world';
    end; // with BlocksList[0]
   
    with BlocksList[1] do
    begin
      some_id := 2;
      some_str := 'Some string';
    end; // with BlocksList[1]
   
    // сериализуем
    fs := TFileStream.Create('test.db', fmCreate);
    try
      BlocksList.SaveToStream(fs);
    finally
      fs.Free;
    end;
   
  finally
    BlocksList.Free;
  end;
 
  // десериализуем
  // создадим чистый список для чистоты эксперимента
  BlocksList := TBlocksList.Create;
  try
    fs := TFileStream.Create('test.db', fmOpenRead);
    try
      BlocksList.LoadFromStream(fs);
    finally
      fs.Free;
    end;
   
    // и чего же мы десериализовали?
    len := BlocksList.Count;
    writeln('loaded ', len, ' blocks:');
    writeln;
    for i := 0 to len-1 do
    begin
      with BlocksList[i] do
      begin
        writeln('block #', len+1);
        writeln('some_id:  ', some_id);
        writeln('some_str: ', some_str);
        writeln;
      end;
    end; // for i
   
  finally
    BlocksList.Free;
  end;
 
end.

Насчет "нужна или нет БД" см. мой предыдущий ответ Attid-у: БД и СУБД - разные вещи, и я стараюсь не смешивать два этих понятия. SQlite, FB и т.п. - это СУБД, а создаваемые ими файлы - это файлы, в которых хранится БД.

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

К своему стыду должен признаться, что до сих пор не понимаю разницы в паскале между class и object. Оба имеют методы и свойства, а в чем различия?

Очень грубо говоря в друх словах:
object - это record с полями и методами
class - это указатель на object
+ все классы хочешь не хочешь наследуют от TObject

[Troublemaker]

Код:

Спасибо, изучаю.

С тем же успехом вордовский документ тоже можно было бы назвать базой данных.

Нельзя - из-за слабой структурированности данных документы обычно относят к "базам знаний".

class и object

Еще раз спасибо. Основу уловил, а дальше уже буду копать, если потребуется.

[v-t-l]

1. Если нужно зашифровать БД, то sqlite, firebird не пойдут

SQLite в последних версиях поддерживает vfs. То есть можно создать свой интефейс к файловой системе и шифровать данные налету, по мере обращения к файлу БД. Правда, задачка это не тривиальная .

[alexs]

да и в птице можно реализовать шифрование. метаданные конечно пока нет, но данные можно через udf-ки сделать или просто на стороне клиента шифровать.

[v-t-l]

Кстати, как вариант - в SQLite есть специальная база ":memory:".
То есть, (на примере ZeosDBO):

Код: Выделить всё

ZConnection.Protocol := 'sqlite-3';
ZConnection.Database := ':memory:';
ZConnection.Connected := True;
ZSQLProcessor.Script.Text := 'CREATE TABLE tbl1 (MyField1 VARCHAR(10), MyField2 INTEGER)';
ZSQLProcessor.Execute;
ZTable1.TableName := 'tbl1';
ZTAble1.Open;


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

Добавлено спустя 12 минут 23 секунды:
Да, и если поле при создании таблицы описать как MyField3 BOOLEAN, то даже CheckBox-ы в гриде отображаются сразу

Добавлено спустя 9 минут 1 секунду:
И еще. Можно не заморачиваться со структурой файла данных, а делать его в виде SQL-скрипта с INSERT-ами.
Правда, над сохранением результатов придется повозиться .

Добавлено спустя 16 минут 11 секунд:
Во идеи поперли!
А если в этом скрипте описывать еще и структуру и внутренюю логику БД - это ж какая гибкость получиться.
Правда управлять внешним видом приложения из этого скрипта не сильно удастся.