Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Какой выбрать разделитель при передаче параметров [D7, WinXP]

Страницы: 1 2 3 >
Mephala © (2008-09-05 10:47:00)
Доброго всем дня!
Необходимо параметры функции записать в строку, а затем строку распарсить и выбрать оттуда все параметры (пишется провайдер между программами). Параметрами могут быть, как числа, дата и время, текст, так и массивы, ссылки и объекты.
Среда разработки - Delphi 7.
Какой лучше выбрать для этого разделитель? Точка с запятой, запятая, пробелы могут встретиться в тексте, ковычки - тоже не очень как-то.
Может кто-нибудь сталкивался с такой проблемой? Поделитесь, пожалуйста, опытом.
Спасибо!

Медвежонок Пятачок (2008-09-09 13:03:00) [1]
Да, кстати, СУБД - Advantage SQL.

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

Медвежонок Пятачок (2008-09-09 12:45:00) [2]
Затраты времени на парсинг хмл будут на порядки ниже времени отклика sql сервера.
Так что ко второму пришествию сумеешь в совокупности сэкономить минут двадцать, не применяя xml.

А моему провайдеру все равно - сколько там параметров.

Ему не все равно. Он всегда точно знает их порядок в стриме и ждет что они придут все именно в таком порядке.

Mephala (2008-09-09 11:37:00) [3]
Да уж, дискуссия получилась горячей, однако! :) А главное - интересной и информативной.
Что же касается удаленного параметра, то в нашем случае с этим проблем нет: так как хранимые процедуры на sql и передаваемые параметры с клиента формируются и изменяются синхронно. А моему провайдеру все равно - сколько там параметров.
Узким местом в моей задаче является время выполнения моей дельфовой хранимой процедуры по обработке входящих параметров. XML безусловно хорош, но в рантайме, да еще с сотней пользователей - это будет беда, имхо. К тому же у нас еще используются коды в режиме JIT, что тоже заставляет задуматься о производительности.
Поэтому мне больше понравилась идея Юрия Зотова, за что ему отдельное спасибо :).
Всем большое спасибо за отклик! Поверьте, узнать опыт профессионалов-практиков, дорого стоит. :)

Медвежонок Пятачок (2008-09-08 14:29:00) [4]
мир всегда кажется таким простым, когда ветку читаешь по диагонали и с середины.

Servy (2008-09-08 14:12:00) [5]
> Он больше не нужен, но для того, чтобы прежние версии не
> дали дуба, вы вынуждены оставлять его в потоке.

А кому он там мог помешать? Раньше использовался, теперь нет - ну длина нулевая для обратной совместимости. Или это маниакальное желание сэкономить 4 байта? Дык в xml проигрыш по размеру заведомо больше.

Единственным доступным моему пониманию плюсом xml является текстовый вид данных, который удобен там, где эти данные кто-то будет править руками. Однако, речь вроде шла о бинарных данных, так что сей плюс неактуален. А значит реализовывать нужно то, что автору удобнее. Мне в случае с бинарными данными, удобнее сделать простетский бинарный формат вроде того, что в [20]. Потому что парсеров xml развелось немало (я штук 6 находил под делфи, искал не слишком усердно), у каждого свои недостатки (а зачастую и баги). Тогда как бинарный формат из серии "простота залог здоровья", весь код мой, и, я подозреваю, он уместится на одном экране (т.е. вероятность наличия в нем ошибки очень близка к нулю).

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

KilkennyCat (2008-09-08 12:35:00) [6]

> xml решение более гибко, более быстро реализуемо, и менее
> трудоемко поддерживаемо.
>

Согласен.
Но фиг знает, какая все-таки кокретная задача именно тут.
Под конкретную задачу может и ваще без разделителя можно обойтись, передавая блоки фиксированного размера. И быстро, и просто. Объемно лишь.

Медвежонок Пятачок (2008-09-08 12:16:00) [7]
Автору вопроса:
Главные итоги ветки можно найти в [37]

Медвежонок Пятачок (2008-09-08 12:12:00) [8]
Да ради бога.
Я утверждал и утверджаю, что xml решение более гибко, более быстро реализуемо, и менее трудоемко поддерживаемо.

В ответ не аргументы - а только пустые слова про "это только слова"

Юрий Зотов (2008-09-08 12:09:00) [9]
> Медвежонок Пятачок © (08.09.08 11:58) [36]

> И я полностью согласен с предложением "поменьше пустых слов".

Ссылку, плз - где в этой ветке я пускался в философские рассуждения о правде жизни и ее реалиях? Конкретно.

> Осталось и вам последовать ему.

Я и последую. Поскольку споре с Вами, как выяснилось, любые слова действительно оказываются пустыми, я просто не буду произносить никаких слов. Чао.

Медвежонок Пятачок (2008-09-08 12:06:00) [10]
В третий раз - ни фига подобного. Например, отрицательная длина параметра означает, что он удален и клиентом должен интерпретироваться соответственно. Как именно - решает сам клиент.

<Цитата>

И в сотый раз: и где здесь удаленный параметр?
Он больше не нужен, но для того, чтобы прежние версии не дали дуба, вы вынуждены оставлять его в потоке.

Медвежонок Пятачок (2008-09-08 12:03:00) [11]
вся продвинутость самопального велосипеда: часы заьраченные на реализацию протокола и несколько выигранных у меня миллисекунд на рантайме.

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

все.

Юрий Зотов (2008-09-08 12:03:00) [12]
> Медвежонок Пятачок © (08.09.08 11:48) [34]

> Читающий алгоритм знает, что вот сейчас идет длина строки, затем сама
> строка, затем дворд, затем снова длина строки после чего строка.

Пожалуста, будьте внимательнее. Читающий алгоритм знает, что идет длина параметра, затем тело параметра. А никакие не строки и не DWORDы. Это уж он сам решает, как ему считанный параметр интерпретировать.

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

> Удаляем один параметр и весь алгоритм улетает в космос.

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

Медвежонок Пятачок (2008-09-08 11:58:00) [13]
Еще раз - ни фига подобного. Параметр удаляется, например, простановкой отрицательной длины и пустого тела. И весь вопрос.

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

И я полностью согласен с предложением "поменьше пустых слов"
Осталось и вам последовать ему.

Юрий Зотов (2008-09-08 11:55:00) [14]
> Медвежонок Пятачок © (08.09.08 11:46) [33]

> Это правда жизни.
> И это не просто слова, а реальность.

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

Но здесь стоит вполне конкретная задача. Та что - давайте конкретно о конкретной задаче и потолкуем, ладно?

> Ваш метод прочитает мусор для удаленного параметра и всех остальных.
> Так как заточен на физический порядок их следования.

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

Медвежонок Пятачок (2008-09-08 11:48:00) [15]
С чего это?

Да с того самого.
Читающий алгоритм знает, что вот сейчас идет длина строки, затем сама строка, затем дворд, затем снова длина строки после чего строка.

Удаляем один параметр и весь алгоритм улетает в космос.
А с xml будет считан один пустой параметр, все остальные останутся на своих местах со своими значениями.

Медвежонок Пятачок (2008-09-08 11:46:00) [16]
Это тоже всего лишь слова.

Это правда жизни.
Ваш метод прочитает мусор для удаленного параметра и всех остальных. Так как заточен на физический порядок их следования.

И это не просто слова, а реальность.

Юрий Зотов (2008-09-08 11:45:00) [17]
> Медвежонок Пятачок © (08.09.08 11:43) [30]

> Он быстрее моего в разы прочитает мусор для всех параметров
> после удаленного.

С чего это?

Юрий Зотов (2008-09-08 11:43:00) [18]
> Медвежонок Пятачок © (08.09.08 11:39) [28]

> только в разы более гибкое и более сопровождаемое в разы.

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

Медвежонок Пятачок (2008-09-08 11:43:00) [19]
Нет. Мой способ тоже прочитает пустоту (длина равна нулю). Только сделает это намного быстрее Вашего.

Он быстрее моего в разы прочитает мусор для всех параметровпосле удаленного.

Юрий Зотов (2008-09-08 11:41:00) [20]
> Медвежонок Пятачок © (08.09.08 11:37) [26]

> кроме того, параметры могут не только добавляться, но и
> удаляться.

Могут.

> мой способ в этом случае в старой версии прочитает пустоту

Прочитает.

> ваш способ прочитает мусор

Нет. Мой способ тоже прочитает пустоту (длина равна нулю). Только сделает это намного быстрее Вашего.

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »