Что выбрать для хранения данных?

← →
_Dima_ (2004-01-06 01:53) [0]

Доброго времени суток!
Запарился над одной проблеммой. Очень надеюсь на вашу помощь!

Не могу определиться со способом храненя данных. Не хочется изобретать велосипед. Лучше использовать готовую технологию. Но вот какую?

Необходимо хранить/обрабатывать данные вида:
__ID_____ИМЯ_____ЦЕНА___
Например:
142 Креветки заморские 120

Таких товаров в базе предвидится 1000-1500.
Нужен эфективный способ добавлять/удалять/изменять эти данные.
Никакие внешние базы данных типа MySQL не подходят. Нужно все хранить в одном файле. Что применить? XML? Если да, то какой компонент лучше использовать, чтобы мучительно долго не разбираться в его работе? И какая будет скорость обработки? А может есть более эффективное решение?

Жду ответов! Заранее спасибо!

← →
Sir Alex (2004-01-06 03:11) [1]

TClientDataSet

← →
Deniz (2004-01-06 08:04) [2]

FireBird Embed/Yaffil Pers - твоя программа + база(все в одном :) файле) + пара файлов, копируешь и все!
Полноценный сервер, рекомендую!
Вот!

← →
Sergey13 (2004-01-06 08:27) [3]

>Никакие внешние базы данных типа MySQL не подходят.
Интересно, почему такое ограничение?

← →
Polevi (2004-01-06 09:09) [4]

msxml parser

← →
Johnmen (2004-01-06 09:14) [5]

Просто обычный файл. Но, естественно, "структурированный"...:)
Грузить его целиком. И работать с ним в памяти.
Скорость будет - просто фантастика !

← →
Sergey_Masloff (2004-01-06 09:40) [6]

Johnmen © (06.01.04 09:14) [5]
совершенно верно

← →
Polevi (2004-01-06 09:49) [7]

>Sergey_Masloff (06.01.04 09:40) [6]
вам знакомо слово "интеграция" ?

← →
Danilka (2004-01-06 09:53) [8]

[5] Johnmen © (06.01.04 09:14)
[6] Sergey_Masloff (06.01.04 09:40)

как правило, когда есть таблица с "ID", "ИМЯ" и "ЦЕНА" то потребуется сортировка, фильтрация, какая-нибудь сложная выборка, отображение в гриде и т.д. И чтобы не писать все это ручками, проще использовать какого-нибудь наследника датасета, которых куча великая.

Другое дело, как такой вопрос может "запарить". :)

← →
Johnmen (2004-01-06 10:06) [9]

>Danilka © (06.01.04 09:53)

В общем и целом, здесь, как всегда, компромисс. Или диалектика...:)
Если хотим, невзирая ни на что, максимум быстродействия, то всё пишем ручками. И никаких наследников и т.п.
Если иначе - то иначе...:)

← →
paul_k (2004-01-06 10:10) [10]

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

← →
Danilka (2004-01-06 10:20) [11]

[9] Johnmen © (06.01.04 10:06)
А зачем на 1500 записей максимум быстродействия? Разница с датасетом на тех машинках что сейчас в офисах стоят - копейки. :))

Хотя, согласен что все это болтовня, по тем условиям которые заданы в теме вполне достаточно типизированого файла. Особенно с учетом:
[10] paul_k © (06.01.04 10:10)
если это и правда какой-нибудь курсовик.

← →
Johnmen (2004-01-06 10:22) [12]

>Danilka © (06.01.04 10:20)
>А зачем на 1500 записей максимум быстродействия?

Не знаю. Потому и говорил "если".

← →
Sergey_Masloff (2004-01-06 12:18) [13]

Polevi © (06.01.04 09:49) [7]
>>Sergey_Masloff (06.01.04 09:40) [6]
>вам знакомо слово "интеграция" ?
Мне знакомо слово производительность. У меня сейчас 750 оффлайновых точек установки программы. С каждой ежедневно сливаются данные. Опционно в XML и собств. формате (не совсем типизированый файл но что-то в этом роде). Размер каждого файла 5-30 Мб. XML в таких условиях просто неконкурентоспособен - разбор своего формата быстрее на несколько порядков (у меня есть конкретная статистика, но это не так важно). Если вдруг понадобится интеграция то конвертор своего формата в XML я напишу за полдня. Только интеграция с помощью XML это миф (по крайней мере пока).

← →
Sandman25 (2004-01-06 12:28) [14]

[13] Sergey_Masloff (06.01.04 12:18)

CSV файлы рулят?

← →
Vlad (2004-01-06 12:28) [15]

> Sergey_Masloff (06.01.04 12:18) [13]

> XML в таких условиях просто неконкурентоспособен -разбор своего формата быстрее на несколько порядков

Речь конечно идет о парсере MSXML?
Есть другие парсеры для XML формата, например SAX. У него скорость во много раз больше чем MSXML. Так что есть ли смысл изобретать свои форматы ?

← →
Danilka (2004-01-06 12:46) [16]

[15] Vlad © (06.01.04 12:28)
верно, смысла нет.
всего 3 поля: два числовых, одно текстовое.
обычный типизированный файл, и нефиг изобретать какие-то форматы и парсеры для них. :))

← →
Sergey_Masloff (2004-01-06 12:46) [17]

Vlad © (06.01.04 12:28) [15]
Ни фига не больше у него скорость. Просто MSXML раньше "построчно" разбирать не мог - только документ целиком в память а потом... Сейчас (и уже давно) умеет так что когда мне нужен парсер XML-мой выбор msxml

← →
Sergey_Masloff (2004-01-06 12:48) [18]

Danilka © (06.01.04 12:46) [16]
>верно, смысла нет.
>всего 3 поля: два числовых, одно текстовое.
>обычный типизированный файл, и нефиг изобретать какие-то >форматы и парсеры для них. :))
Прочти внимательно несколько мессаджей вверх. Для задачи автора - ничегокроме типизированного файла я не предлагал.

← →
Danilka (2004-01-06 12:48) [19]

[18] Sergey_Masloff (06.01.04 12:48)
читал, знаю. поэтому и не тебе отвечал. :))

← →
Sergey_Masloff (2004-01-06 12:49) [20]

Sandman25 © (06.01.04 12:28) [14]
>[13] Sergey_Masloff (06.01.04 12:18)
>CSV файлы рулят?
нет конкретно у меня данные иерархические. Вернее даже там граф, в принципе можно извернуться но мне проще как сделано. И работает с КОСМИЧЕСКОЙ скоростью. Серьезно.

← →
Polevi (2004-01-06 12:50) [21]

Sergey_Masloff (06.01.04 12:18) [13]
про несколько порядков не верю, и в конце концов не так сложно написать свой парсер если не устраивает производительность готовых
вот вы напишите за полдня а если уволитесь, кто будет вашу кашу разгребать ?

← →
Sandman25 (2004-01-06 12:54) [22]

[20] Sergey_Masloff (06.01.04 12:49)

Понятно. Если под космической скростью Вы тоже понимаете скорость работы с винчестером :)

← →
Sergey_Masloff (2004-01-06 14:32) [23]

Polevi © (06.01.04 12:50) [21]
>Sergey_Masloff (06.01.04 12:18) [13]
>про несколько порядков не верю,
Мамой клянус! ;-))
Нет, правда. При работе с msxml время в минутах на 15Мб файл и потом растет в прогрессии быстрее линейной. В моем случае все в real-time.

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

← →
Erik (2004-01-06 15:50) [24]

Написал бы автор, что ему подходит больше. Вобщем отзыв автора нужен. А то предложиить можно целую кучу. Например взять готовый наследник от TDataSet, без индексов и славаря мета данных. Идеш на Torry.net береш с исходниками, что тебе по душе. После обрезаеш до необходимого минимума. Но такой мотод можно порекомендовать в спечефических условиях. Кто знает, что это за проект?!

← →
kaif (2004-01-07 00:22) [25]

Используй компонент таблицы в памяти с сохранением на диске. Например, TkbmMemTable.

Что выбрать для хранения данных? Найти похожие ветки