declare a int, b char(32), c varchar(50);

[vg]

Можно ли как в T-SQL, вместо

declare a int;
declare b char(32);
declare c varchar(50);

в MySQL. Уныло как-то. Можно ли в одной строке?

[Earl Grey]

Можно ли как в T-SQL, вместо

declare a int;
declare b char(32);
declare c varchar(50);

в MySQL. Уныло как-то. Можно ли в одной строке?

Чернила экономишь?

[vg]

Можно ли как в T-SQL, вместо

declare a int;
declare b char(32);
declare c varchar(50);

в MySQL. Уныло как-то. Можно ли в одной строке?

Чернила экономишь?

В тех процедурах, что я прилаживаю (рыинженерю) этот список бывает из 15-20 переменных. declare много раз печатать надо тогда.
Да и не забавно. Почему они (студенты, что придумали MySQL) не могут распарсить одно выражение, с одним declare.

[Earl Grey]

В тех процедурах, что я прилаживаю (рыинженерю) этот список бывает из 15-20 переменных. declare много раз печатать надо тогда.

Печатать? А что, copy/paste уже не в моде

Да и не забавно. Почему они (студенты, что придумали MySQL) не могут распарсить одно выражение, с одним declare.

Одна строка declare для 15-20 переменных РАЗНЫХ типов, IMHO, будет сильно ухудшать читабельность кода.

[vg]

В тех процедурах, что я прилаживаю (рыинженерю) этот список бывает из 15-20 переменных. declare много раз печатать надо тогда.

Печатать? А что, copy/paste уже не в моде

Да и не забавно. Почему они (студенты, что придумали MySQL) не могут распарсить одно выражение, с одним declare.

Одна строка declare для 15-20 переменных РАЗНЫХ типов, IMHO, будет сильно ухудшать читабельность кода.

declare
a int,
b char(32),
c varchar(50);

[AlexANB]

Можно ли как в T-SQL, вместо

declare a int;
declare b char(32);
declare c varchar(50);

в MySQL. Уныло как-то. Можно ли в одной строке?

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

Е-мое! да у меня редактор текстов 95% всего заполняет в таких ситуациях!

Если это у вас до сих пор проблема -- чем вы занимались последние 15 лет? Неужели программированием? Не верю!

[vg]

Можно ли как в T-SQL, вместо

declare a int;
declare b char(32);
declare c varchar(50);

в MySQL. Уныло как-то. Можно ли в одной строке?

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

Е-мое! да у меня редактор текстов 95% всего заполняет в таких ситуациях!

Если это у вас до сих пор проблема -- чем вы занимались последние 15 лет? Неужели программированием? Не верю!

Танцую.
А ты как видно поёшь.

[Earl Grey]

В тех процедурах, что я прилаживаю (рыинженерю) этот список бывает из 15-20 переменных. declare много раз печатать надо тогда.

Печатать? А что, copy/paste уже не в моде

Да и не забавно. Почему они (студенты, что придумали MySQL) не могут распарсить одно выражение, с одним declare.

Одна строка declare для 15-20 переменных РАЗНЫХ типов, IMHO, будет сильно ухудшать читабельность кода.

declare
a int,
b char(32),
c varchar(50);

Ага, а через месяц ты забудешь какого типа переменная с. И как ты будешь это выяснять?

Искать строку "с"? Или строку "declare", а потом глазками парсить?

Может быть проще искать "declare c"?

[vg]

Ага, а через месяц ты забудешь какого типа переменная с. И как ты будешь это выяснять?

Искать строку "с"? Или строку "declare", а потом глазками парсить?

Может быть проще искать "declare c"?

Часто программы пишутся, когда не только через месяц, но и через два года не надо вспоминать, что означает переменная "c". Это как в администрировании - один раз настоил, а потом искусство администратора состоит в том, чтобы ничего не трогать.

Ты немного не понял, о чём я, или я недосказал. Мне сейчас надо переписать около 50 хранимых процедур, чтобы перехать существующую базу с MSSQL на MySQL. Поэтому, хотелось бы менять процедуры, функции, триггеры с минимальными затратами времени и с минимальной редакцией кода T-SQL. Надо делать очень быстро, поскольку кроме обработки бизнец логики на базе энд, надо определиться с клиенской часть, ибо как показал первоначальный опыт могут появиться неожиданные проблеммы с MySQL ADO v.3.5. Версия 5.0 полна багов.

[Earl Grey]

Ты немного не понял, о чём я, или я недосказал.

Чего уж тут не понять? Известный принцип: после меня - хоть потоп.

Мне сейчас надо переписать около 50 хранимых процедур, чтобы перехать существующую базу с MSSQL на MySQL. Поэтому, хотелось бы менять процедуры, функции, триггеры с минимальными затратами времени и с минимальной редакцией кода T-SQL. Надо делать очень быстро, поскольку кроме обработки бизнец логики на базе энд, надо определиться с клиенской часть, ибо как показал первоначальный опыт могут появиться неожиданные проблеммы с MySQL ADO v.3.5. Версия 5.0 полна багов.

Речь идет о примерно 1000 определений. Всего-то Причем оригинальные процедуры писал такой же экономист-торопыга. Ты пожинаешь плоды его уверенности что намного важнее определиться с чем бы то ни было ... Я правда не понимаю, почему нельзя думать над клиентской частью во время выполнения copy/paste

Правда, если "определяться" с такой же скоростью, то тому, кто придет на твое место, вы, похоже, еще много сюрпризов приготовите

[vg]

Рассматривается несколько вариантов миграции, на разные сервера. То как это будет выглядить в окончательном виде, и то что делается сейчас мною - две большие разницы. Вы видимо считаете, что базу можно просто начинать мигрейт не исследовав хорошенько предварительно последствия такой миграции. Мы вначале протестируем тестовые базы на разных платформах и выберем для последующей окончательно имплементации то, что нам подойдёт.

Я правда не понимаю, почему нельзя думать над клиентской частью во время выполнения copy/paste

Про клиентскую часть можно здесь подробнее, если вы, конечно, имеете ввиду программирование на каком-нибудь компьютерном языке с ипользование ADO (ADO это специальные COM объекты).

Ред.
ПС. Ещё пояснение .... До клиентской части может дело не дойти из-за ограниченности и специфики языка, недоработанности DB драйверов, например, невозможности (или ненадёжности) возврата рекордсет, возврата значений в объектах параметров ADO и прочих скучных программистских

[Earl Grey]

Рассматривается несколько вариантов миграции, на разные сервера. То как это будет выглядить в окончательном виде, и то что делается сейчас мною - две большие разницы. Вы видимо считаете, что базу можно просто начинать мигрейт не исследовав хорошенько предварительно последствия такой миграции. Мы вначале протестируем тестовые базы на разных платформах и выберем для последующей окончательно имплементации то, что нам подойдёт.

Я правда не понимаю, почему нельзя думать над клиентской частью во время выполнения copy/paste

Про клиентскую часть можно здесь подробнее, если вы, конечно, имеете ввиду программирование на каком-нибудь компьютерном языке с ипользование ADO (ADO это специальные COM объекты).

Ред.
ПС. Ещё пояснение .... До клиентской части может дело не дойти из-за ограниченности и специфики языка, недоработанности DB драйверов, например, невозможности (или ненадёжности) возврата рекордсет, возврата значений в объектах параметров ADO и прочих скучных программистских

Перечитал. Абсолютно не понял, как то, что написал я, превратилось в то, о чем ты здесь пишешь?

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

Это следует из каких моих слов?

"Про клиентскую часть можно здесь подробнее, если вы, конечно, имеете ввиду программирование на каком-нибудь компьютерном языке с ипользование ADO (ADO это специальные COM объекты)."

А это о чем?

Я полемизировал вот с этим:

"Надо делать очень быстро, поскольку кроме обработки бизнец логики на базе энд, надо определиться с клиенской часть"

[vg]

Перечитал. Абсолютно не понял, как то, что написал я, превратилось в то, о чем ты здесь пишешь?

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

Это следует из каких моих слов?

"Про клиентскую часть можно здесь подробнее, если вы, конечно, имеете ввиду программирование на каком-нибудь компьютерном языке с ипользование ADO (ADO это специальные COM объекты)."

А это о чем?

Я полемизировал вот с этим:

"Надо делать очень быстро, поскольку кроме обработки бизнец логики на базе энд, надо определиться с клиенской часть"

Нет смысла вылизывать SQL код процедур (в сравнении с тем, что уже работало годы) в задаче миграции на опенсорс платформу, если при предварительном исследовании ещё не ясно, как будут работать вся инф. система. Это как бы движется по кругу (вернее по спирали).
Если становится очевидно, что на "новой" платформе всё должно работать хорошо, и откатиться к старому можно быстро, тогда можно начинать серьёзную работу по "вылизыванию".

ПС. Философские заметки....
Хочу ещё заметить моё собственное отношение к хорошему коду, о котором возможно вы говорите:
1) хорошим, "вылизанным" кодом, код часто остаётся только в представлении того программиста, который пишет этот код. И это мнение может сильно расходиться с мнением других программистов. Это болезнь РФ/CCCP программистов - программирование за деньги конторы для себя.
2) в реальных бизнес условиях не всегда есть время на то, чтобы придать коду монументальную законченность.
3) монументально-законченный код некого приложения, гордость программиста, часто приходится переписывать, ибо он не настолько хорош. Всё в топку. Кстати сам автор монументального кода часто приходит к такомуже заключению, просматривая свои гениальности через годик, другой.