База на основе txt файла
Модераторы: Hawk, Romeo, Absurd, DeeJayC, WinMain
Копать в сторону sscanf(); :-)
-
- Сообщения: 1228
- Зарегистрирован: 26 фев 2004, 13:24
- Откуда: Pietari, Venäjä
- Контактная информация:
Встеречал как-то одного человека, который очень любил циклы с разборами, но при этом не мог отладить свой код.Копать в сторону sscanf();
forum/viewtopic.php?t=2503
2B OR NOT(2B) = FF
Наверное будет уместно, если я предложу использовать DataSet
Усложнять - легко, упрощать - сложно
Если судить по разговору, то мнения можно разделить на две категории: одни являются сторонниками примитивных функций стандартной библиотеки С/С++, другие склонны исключительно к высокоуровневым компонентам и технологиям. Лично моё мнение такое: запись в текстовый файл можно осуществлять как угодно, хоть обычными функциями типа fprintf(), потому как структура данных в текстовом файле программисту уже заранее известна, лишь бы конечный результат был корректным. А вот для чтения данных лучше использовать более интеллектуальные средства, и здесь уже необходимо исходить из условий конкретной задачи и требований заказчика. При этом я не берусь однозначно утверждать, какая из существующих технологий лучше...
Помню как-то давно я делал небольшую базу данных на основе текстового INI-файла. В качестве имён секций я использовал имена полей предполагаемой таблицы, а номера записей - как ключи в секциях.
Для чтения и записи данных использовались функции Win32API GetPrivateProfileString(), WritePrivateProfileString(), GetPrivateProfileSection(). И у меня такая программка очень даже неплохо работала, правда было ограничение на размер INI-файла.
Помню как-то давно я делал небольшую базу данных на основе текстового INI-файла. В качестве имён секций я использовал имена полей предполагаемой таблицы, а номера записей - как ключи в секциях.
Для чтения и записи данных использовались функции Win32API GetPrivateProfileString(), WritePrivateProfileString(), GetPrivateProfileSection(). И у меня такая программка очень даже неплохо работала, правда было ограничение на размер INI-файла.
-
- Сообщения: 1228
- Зарегистрирован: 26 фев 2004, 13:24
- Откуда: Pietari, Venäjä
- Контактная информация:
Какие такие высокоуровневые компоненты и технологии? Речь идет о одной из грубейших и типичнейших архитектупных ошибок, которые допускют молодые программисты - изобретение велосипедов из-за неофобии и леность.
Вот XML файл.
Вот код. Обратите внимание на XPath запрос
config/section1/property[@name="name1"]/@value
Это статическое правило. В нем не может быть ошибок.
Конфиг этот может быть любой сложности. По мере роста программы он сможет усложняться как угодно, безо всяких подпорок которые приводят программу к неподдерживаему состоянию.[/code]
Вот XML файл.
Код: Выделить всё
<?xml version="1.0" encoding="utf-8"?>
<config>
<section1>
<property name="name1" value="Is it difficult?" />
</section1>
</config>
config/section1/property[@name="name1"]/@value
Это статическое правило. В нем не может быть ошибок.
Конфиг этот может быть любой сложности. По мере роста программы он сможет усложняться как угодно, безо всяких подпорок которые приводят программу к неподдерживаему состоянию.
Код: Выделить всё
int _tmain(int argc, _TCHAR* argv[])
{
CoInitialize(NULL);
try {
CComPtr<IXMLDOMDocument> spXMLDOM;
HRESULT hr = spXMLDOM.CoCreateInstance(__uuidof(DOMDocument));
if(FAILED(hr)) {
throw DOMError();
}
if ( spXMLDOM.p == NULL ) {
throw DOMError();
}
VARIANT_BOOL bSuccess = false;
hr = spXMLDOM->load(CComVariant(L"config.xml"), &bSuccess);
if ( FAILED(hr) ) {
throw DOMError();
}
if ( !bSuccess ) {
throw DOMError();
}
CComBSTR bstrSS(L"config/section1/property[@name=\"name1\"]/@value");
CComPtr<IXMLDOMNode> spXMLNode;
hr = spXMLDOM->selectSingleNode(bstrSS,&spXMLNode);
if ( FAILED(hr) ) {
throw DOMError();
}
if ( spXMLNode.p == NULL ) {
throw DOMError();
}
CComBSTR result;
spXMLNode->get_text(&result.m_str);
std::wcout<<(BSTR)result<<L'\n';
} catch (...) {
CoUninitialize();
throw;
}
return 0;
}
2B OR NOT(2B) = FF
-
- Сообщения: 497
- Зарегистрирован: 17 фев 2004, 11:26
- Откуда: Ленинград (который Город на Неве)
- Контактная информация:
WinMain, подобное решение было отправлено в пень, как только
понадобилась кросс-платформенность и иерархия. Пришлось извращаться типа
[section]
property1.subprop1......
А xml всё это умеет.
Absurd А вот Херес умеет всё это делать без всяких com-овских извратов, кстати....
понадобилась кросс-платформенность и иерархия. Пришлось извращаться типа
[section]
property1.subprop1......
А xml всё это умеет.
Absurd А вот Херес умеет всё это делать без всяких com-овских извратов, кстати....
"Особое внимание начинающих аквариумистов хотим обратить на то, что рыбки никогда не спят на спинке!" (c)
viel spass, DeeJayC
viel spass, DeeJayC
-
- Сообщения: 1228
- Зарегистрирован: 26 фев 2004, 13:24
- Откуда: Pietari, Venäjä
- Контактная информация:
Я не любитель написания портируемых программ (мини-осей) на С++.А вот Херес умеет всё это делать без всяких com-овских извратов, кстати....
Если уж писать native код, то надо использовать все приемущества среды.
2B OR NOT(2B) = FF
Absurd, вот в C# интерпретации
И крутим данные как угодно(например выводим названия<name>)
Простота и расширяемость налицо.
Код: Выделить всё
<?xml version="1.0" encoding="utf-8" ?>
<main>
<version>1.1</version>
<log_days>days.xml</log_days>
<passwords>passwd.xml</passwords>
<shop>
<id>1</id>
<name>Голубинка</name>
<data>d_golyb.xml</data>
<enabled>true</enabled>
</shop>
<shop>
<id>2</id>
<name>Баляева</name>
<data>d_bal.xml</data>
<enabled>true</enabled>
</shop>
<shop>
<id>3</id>
<name>Ладыгина</name>
<data>d_ladi.xml</data>
<enabled>true</enabled>
</shop>
Код: Выделить всё
using System;
using System.Data;
using System.IO;
using System.Xml;
using System.Windows.Forms;
namespace myXml
{
/// <summary>
/// Summary description for usexml.
/// </summary>
public class usexml
{
public DataSet xml;
private string file_name_xml = null;
public usexml(string filename)
{
this.file_name_xml = filename;
this.xml = new DataSet();
this.xml.ReadXml(this.file_name_xml);
this.xml.AcceptChanges();
}
}
}
Код: Выделить всё
usexml cxml = new usexml("_conf.xml");
object [] dat = new object [3];
DataTable table = cxml.xml.Tables["shop"];
foreach(DataRow row in table.Rows)
{
dat = row.ItemArray;
Console.WriteLine(dat[0].ToString() + dat[1].ToString());
}
Усложнять - легко, упрощать - сложно
Вы случаем не забыли тему?
Вообще то использование XML или TXT или SQL определяется задачей.
Если приложение должно быть лехким то подключение XML или SQL не правитьно, если обьем данных большей то лудьше использовать SQL (индексы), если важно универсальный подход можно использовать XML (и не обязательно от MS).
А по поводу TXT данных то вопрос в том что за файл и как он был получен без этого болтать не очем.
Вообще то использование XML или TXT или SQL определяется задачей.
Если приложение должно быть лехким то подключение XML или SQL не правитьно, если обьем данных большей то лудьше использовать SQL (индексы), если важно универсальный подход можно использовать XML (и не обязательно от MS).
А по поводу TXT данных то вопрос в том что за файл и как он был получен без этого болтать не очем.
ssDev, вот случаем и не забыли 
Вообще, прежде чем выбирать TXT, XML или SQL следует разобрать некоторые моменты. Постановка задачи может повлиять, если явно все заданно. А если выбор стоит перед программистом, то как ему поступить?
1. TXT В принципе, если написать свой парсер, то можно с легкостью работатьс такой БД. Но есть ряд довольно критических ограничений: скорость и расширяемость. Ну и конечно же первое противоречит второму. При условии, что база у нас небольшая мы можем например загружать все данные в память с предворительным либо последующим разбором их(получаем огромный расход памяти, но экономим процессорное время в последуюмщем). А можем постоянно обращаться к файлу и извлекать все необходимое походу дела, следовательно получается экономия памяти и постоянная нагрузка на проц. Что касается расширяемости, то человеку писавшему парсер для этого ТХТ при незначитьльном изменении формата данных(например, добавить еще один столбец в нашу абстрактную БД) прийдется несладко(если он не позаботится об этом заранее) .
Вид самой базы будет зависеть исключительно от шаловливых мыслей самого автора, как и полный ее разбор на состовляющие. К примеру можно взять формат csv генерируемый Excel`ем
Как вариант можно построчно считывать данные из файла(соотв. строки, начинающиеся с "//" игнорировать). Если, пойдем по первому пути, то можно аккуратненько разбирать строчки и складывать их в 2-х мерный массив строк. Если по второму, то тут как масть попрет 
2. XML. Он во многом похож, на ТХТ, но под него уже есть множество библиотек облегчающие нашу работу. С расширяемостью тут полный тип-топ, а вот с производительностью опять замуты. Например в С# есть объект DataSet с которым очень приятно работать(хотя тоже неслабо накрученный и есть ряд заморочек). Этот объект позволяет хранить сразу несколько таблиц и он хорошо адаптирован под XML
3. SQL Можно, до бесконечности рассказывать, что БД на основе SQL - это круто, но ставить сервак к простенькому приложению не резон, хотя можно остановиться на выборе Acsses(кажись неправильно написал
), но это уже дело вкуса.
Вот! На данной почве в принципе можно спорить бесконечно долго. Но, я категорически против TXT/

Вообще, прежде чем выбирать TXT, XML или SQL следует разобрать некоторые моменты. Постановка задачи может повлиять, если явно все заданно. А если выбор стоит перед программистом, то как ему поступить?
1. TXT В принципе, если написать свой парсер, то можно с легкостью работатьс такой БД. Но есть ряд довольно критических ограничений: скорость и расширяемость. Ну и конечно же первое противоречит второму. При условии, что база у нас небольшая мы можем например загружать все данные в память с предворительным либо последующим разбором их(получаем огромный расход памяти, но экономим процессорное время в последуюмщем). А можем постоянно обращаться к файлу и извлекать все необходимое походу дела, следовательно получается экономия памяти и постоянная нагрузка на проц. Что касается расширяемости, то человеку писавшему парсер для этого ТХТ при незначитьльном изменении формата данных(например, добавить еще один столбец в нашу абстрактную БД) прийдется несладко(если он не позаботится об этом заранее) .
Вид самой базы будет зависеть исключительно от шаловливых мыслей самого автора, как и полный ее разбор на состовляющие. К примеру можно взять формат csv генерируемый Excel`ем
Код: Выделить всё
// comment
// [b]id[/b];[b]name[/b];[b]family[/b];[b]otchestvo[/b]
1;Сергей;Петров;Иванович
2;Михаил;Сидоров;Валерьевич
3;Иван;Грозный;Васильевич

2. XML. Он во многом похож, на ТХТ, но под него уже есть множество библиотек облегчающие нашу работу. С расширяемостью тут полный тип-топ, а вот с производительностью опять замуты. Например в С# есть объект DataSet с которым очень приятно работать(хотя тоже неслабо накрученный и есть ряд заморочек). Этот объект позволяет хранить сразу несколько таблиц и он хорошо адаптирован под XML
3. SQL Можно, до бесконечности рассказывать, что БД на основе SQL - это круто, но ставить сервак к простенькому приложению не резон, хотя можно остановиться на выборе Acsses(кажись неправильно написал

Вот! На данной почве в принципе можно спорить бесконечно долго. Но, я категорически против TXT/
Усложнять - легко, упрощать - сложно