Посоветуйте, п-та, что предпочтительно использовать для хранения данных. Данные представляют собой информацию о человеке, о компании, названия меню и д.р. Данных немного.
Пока для себя выбрал хранить ODT.Data как более наглядно и читабельно. Плюс все это дело предсатвялется в виде иерерхии. Но мне кажется это слегка извращенно так использовать ODT (Class не испоьзую, пишу свои)
Можно, к-но, хранить и в отдельной переменной или в XML, XLS и т.д. + DDT использовать. Но перегружать проект тоже не хотелось бы.
Хотелось бы знать у кого какие предпочтения и выбрать наиболее простой и элегантный вариант. Возможно, остановлюсь и на ексель файле. Пока данных немного и использую в качестве хранилища ODT.Data.
Используем ексель. Но у этого подхода есть проблемы. Например трудно отслеживать изменения в системах контроля версий. Могут возникнуть проблемы с хранением иерархических данных. Ну плюс сами ограничения драйвера (тыц)
Но в любом случае - самый удобный вариант (имхо :))
Excel рассмартивал в качестве удобства хранения данных. Но вот не сложилось, т.к. данные иерархические, к примеру, это резюме человека - м.б. несколько тел. номеров, опыт работы и т.д. Но это тоже решаемо. Можно XML конечно, так как TestComplete умеет работать с ним. Но пока данных немного выбрал JSON формат в отдельном файле. Либо всех запихну в один файл, либо по одному файлу на каждую сущность. В общем это БД для которой необходим где-то хранить входные тестовые данные. Может через Access извращусь:)
мы для хранения иерархий используем специальный формат значения в ячейке: #LIST(pageName,id1|id2|idN)
где pageName имя таба в экселевском файле, а idX это значение в стобце с именем "ID" (этот столбец есть везде и значения в пределах страницы должно быть уникальными).
Например:
Page 'Customer'
ID | Name| Phones
c1| Vasya| #LIST(phones, p1|p2)
c2| Dupa | +3999999999
Page 'phones'
ID | Phone
p1|25252525
p2|(089)444-555
Смысл понятен. Спасибо за интересную идею. К сожалению, не увидел прозрачности реализации и удобства использования для моей задачи с огромным количеством разнообразных полей (опыт работы, образравние, и т.д.) . Access более интересен с этой точки зрения. Но это по сути придется реализовывать другую базу, упрощенную. Пока остановился на json как наиболее простом и наглядном формате.