Какой выбрать разделитель при передаче параметров

  • Автор темы Mephala
  • Дата начала
Статус
Закрыто для дальнейших ответов.
M

Mephala

#1
Доброго всем дня!
Необходимо параметры функции записать в строку, а затем строку распарсить и выбрать оттуда все параметры (пишется провайдер между программами). Параметрами могут быть, как числа, дата и время, текст, так и массивы, ссылки и объекты.
Среда разработки - Delphi 7.
Какой лучше выбрать для этого разделитель? Точка с запятой, запятая, пробелы могут встретиться в тексте, ковычки - тоже не очень как-то.
Может кто-нибудь сталкивался с такой проблемой? Поделитесь, пожалуйста, опытом.
Спасибо!
 

slavon-x86

Well-known member
18.12.2005
215
0
#3
Сделай с размером !
Т.е. в начале идёт число, которое обозначает число байт данных для параметра которые нужно читать.

К примеру:
Код:
16 Я уехал в африку9 Синий кот7 Тетрадь
 
Z

zubr

#5
Согласен с Kmet - xml самый лучший вариант. Но если все же идти путем разделителя, то самый надежный вариант, применяемый во многих протоколах - это любой символ. Если он встречается в тексте, то удваивается. При парсинге строки пара этих символа преобразуются в один и относятся к тексту, оставшийся к разделителю.
 
M

Mephala

#6
Спасибо большое за ответы. Получается, что одни из лучших - это xml и удвоение символа. А если будут еще передаваться и бинарные данные в строку, то какой из этих лучше использовать?
Сама понимаю, что от велосипедов не деться. Суть такая, что из дельфовой программы нужно передать в хранимую процедуру СУБД (dll) входные параметры. А так как количество входных параметров может быть разным для разных функций, то было принято решение занести все параметры в один. Если у вас есть лучшее решение и пр., то буду рада любой критике :)

И еще вопрос: какие существуют классы, методы, объекты, чтобы парсить и формировать xml? С этим еще не сталкивалась я. Буду рада помощи.
Спасибо!
 
M

Mephala

#7
СУБД - Advantage SQL.
Да, создали одну ХП в длл для универсальности. Эта процедура обрабатывает один входной параметр, разбивает его на массив параметров и передает уже эти параметры нужной внутренней хранимой процедуре СУБД (Advantage SQL). Поэтому и была написана одна универсальная хранимая процедура (ДЛЛ), которая смогла бы обрабатывать множество других процедур и функций, чтобы не клепать множество идентичных самописных длл. Поэтому и было принято решение все параметры засунуть в один. Это легче при интеграции, масштабировании, развертывании и по производительности.
Что скажете?
Есть вариант формирования строки по схеме - длина 1 параметра - первый параметр - длина 2 параметра - второй параметр и т.д. Такой подход мне кажется производительным - только один цикл для строки. Для удвоения - нужно будет несколько циклов, и для xml тоже будет трудоемкий процесс.
Или может еще что-то. Как вы считаете?
 

Kmet

Java Team
25.05.2006
1 036
8
#8
что вы понимаете под длл?

Есть вариант формирования строки по схеме - длина 1 параметра - первый параметр - длина 2 параметра - второй параметр и т.д. Такой подход мне кажется производительным - только один цикл для строки.
багадром... не очевидно как передавать числа, даты и тд

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

согласен с sax_ol, непонятно какие мотивы вас сподвигли на такое неоднозное решение. БД с множеством ХП, которые обеспечат проверку типов, много лучше вашего решения.
 
M

Mephala

#9
Мотивы такие оказались из сложности самой платформы, на котором все работает уже много-много лет. А вот сейчас хочется это все переместить на новый движок на новую СУБД с совместимостью с прошлыми наработками. Другие варианты, как не рассматривали - не подошли. А из-за того что я только часть проекта осветила, а 95% - нет, вот и появляется уверенность, что это очередной велосипед и багадром... :rolleyes:
Вы правы, как никогда :blink: Без этого ни одни проект не создается.
>не очевидно как передавать числа, даты и тд
Как строку. Есть же функции для преобразования типов. С этим как раз проблем не будет.
И БД с множеством ХП как раз и будет. И мой провайдер тоже будет использоваться для конкретных задач.
Спасибо большое всем за отклик!
 

Kmet

Java Team
25.05.2006
1 036
8
#10
Мотивы такие оказались из сложности самой платформы, на котором все работает уже много-много лет. А вот сейчас хочется это все переместить на новый движок на новую СУБД с совместимостью с прошлыми наработками. Другие варианты, как не рассматривали - не подошли. А из-за того что я только часть проекта осветила, а 95% - нет, вот и появляется уверенность, что это очередной велосипед и багадром... smile.gif
уверенность осталась
>не очевидно как передавать числа, даты и тд
Как строку. Есть же функции для преобразования типов. С этим как раз проблем не будет.
будут. как будете разруливать случай, когда передоваемый параметр после преобразования в строку будет начинаться с цифры?
 
Статус
Закрыто для дальнейших ответов.