Замена символов в строке средствами SQL

← →
MZ (2007-09-13 15:09) [0]

Подскажите как средствами SQL заменить любые первые 4 символа в строке

← →
Desdechado © (2007-09-13 15:34) [1]

"1234" || SUBSTRING

← →
MZ (2007-09-13 16:24) [2]

> "1234" || SUBSTRING
>

Я немного н так выразился.... Есть поле Code (Varchar (9)) в котором содержиться
некий код, так вот первые четыре символа этого кода необходимо заменить. и сделать это желательно в XП

← →
Anatoly Podgoretsky © (2007-09-13 16:32) [3]

> MZ (13.09.2007 16:24:02) [2]

А тебе что разве не это привели?
Или ты хочешь полность отлаженый и до конца расписаный код?

← →
MZ (2007-09-13 16:45) [4]

спасибо! просто сразу не разобрался как работает substring :-)

← →
sniknik © (2007-09-13 17:50) [5]

> и сделать это желательно в XП
блин, что за мода пихать все в XП? без реальной необходимости... даже если как в данном случае все можно сделать одним запросом.

p.s. счас программку разбираю на предмет переделки, бо медленная и глючная очень, так вся сплошь на ХП! ни одного простого, честного запроса...
понимаю если бы там делалось что то, а то подавляющее большинство из них имеет вид
CREATE PROCEDURE ProcName as SELECT * FROM TableName
... вот именно так (заменены только имена ProcName и TableName)...
хотя есть и похлеще "перлы" вида
CREATE PROCEDURE ProcName as SELECT * FROM ViewName
вьюшка в которых имеет вид... ну вы догадались... ;о))

← →
Desdechado © (2007-09-13 18:00) [6]

sniknik © (13.09.07 17:50) [5]
Может, автор перлов начитался идеологии "вся бизнес-логика - в ХП", но не понял, что такое бизнес-логика? Или планировал потом усложнять, меняя ХП?

← →
Krantus (2007-09-14 14:33) [7]

> sniknik © (13.09.07 17:50) [5]
> > и сделать это желательно в XП
> блин, что за мода пихать все в XП? без реальной необходимости.
> .. даже если как в данном случае все можно сделать одним
> запросом.

для справки. как это в данном случае одним запросом?

← →
PEAKTOP © (2007-09-14 15:10) [8]

> Может, автор перлов начитался идеологии "вся бизнес-логика - в ХП",

А что в этом плохого ? Потом дорабатывать симметричную WWW-систему на Apache+PHP просто прелесть: одинаковое поведение объектов БД не зависимо от способа доступа.

← →
Anatoly Podgoretsky © (2007-09-14 15:12) [9]

Ну, ну

← →
Desdechado © (2007-09-14 15:26) [10]

> как это в данном случае одним запросом?
UPDATE tbl SET fld = "1234" || SUBSTRING(...) WHERE fld = SUBSTRING(...)

PEAKTOP © (14.09.07 15:10) [8]
В идее плохого нет, реализация ужасная.

← →
Val © (2007-09-15 11:44) [11]

>[5] sniknik © (13.09.07 17:50)
это может быть удобно при раздаче прав.

← →
Petr V. Abramov © (2007-09-15 16:04) [12]

во-первых, [11], во-вторых, при изменени структуры базы не отвалится клиент.

← →
sniknik © (2007-09-15 21:56) [13]

> В идее плохого нет, реализация ужасная.
а любая идея только плохого содержать не может, везде есть плюсы и минусы. плохо только фанатичное следование оным. (что в этом топике и угадывается... минимальное действие, без всяких предпосылок но уже "желательно в XП")

> это может быть удобно при раздаче прав.
и часто ты правами рулишь? направо и налево, в прогах "hello base!". ;о)

а как подобное повлияет на удобность обработки данных? например на выборку данных из одной таблицы по зависящим критериям из другой. (джоин с условием по данным обоих)
покажи на примере 2-х процедур с приведенной структурой.
(кстати, то как подобного рода обработки сделаны в этой "уже моей" (пока еще надеюсь "отмазаться") в основном и влияет на ее "тормознутость", ну плюс еще и отсутствие индексов, кроме ключей (хоть тут нормально), и отсутствие отключения контролов даже в переоткрытии процедуры по таймеру... дальше не смотрел, бросил, надо все с 0 писать, быстрее будет чем переделывать. хотя еще лучше ничего не делать, пусть пользуются тем что есть... может поймут зачем в конторе программистский отдел, и что админ<>программист даже если он на досуге чтото и написал)

> во-первых, [11], во-вторых, при изменени структуры базы не отвалится клиент.
привожу процедуру еще раз
CREATE PROCEDURE ProcName as SELECT * FROM TableName
меняем структуру таблицы, к примеру поле name на firstname (естественно не меняем саму процедуру, о ней речи не было)
клиент не отвалится? ну ну.
и тот же вопрос. как часто ты меняешь структуру базы? не на этапе разработки, а уже в релизе. и главное так чтобы меняя базу ничего не трогать в клиенте.
???
я вот честно не помню за собой такого... всегда было наоборот, требования добавить чтото в программу тянуло за собой изменения базы (ну нет соответствующих полей/таблиц...). а так чтобы переделать базу не пойми с чего, и чтобы не изменять клиента. ну не было...
ну вот действительно, а с чего? если клиентская прога работает, устраивает и менять в ней ничего не надо. что в этом случае может заставить менять структуру базы?

← →
Petr V. Abramov © (2007-09-15 23:06) [14]

> CREATE PROCEDURE ProcName as SELECT * FROM TableName
меняем структуру таблицы, к примеру поле name на firstname (естественно не меняем саму процедуру, о ней речи не было)
клиент не отвалится? ну ну.

на клиенте TableName используется 100 раз и неизвестно где, в хранимке - один раз и по dependecies можно вычислить или как у вас там в mssql называется

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

← →
sniknik © (2007-09-16 01:21) [15]

Petr V. Abramov © (15.09.07 23:06) [14]
в умении не понимать очевидного, написанного черным по серому, вам не откажешь...

> на клиенте TableName используется 100 раз и неизвестно где, в хранимке - один раз и по dependecies можно вычислить
зачем вычислять? разве программа/база не ваши, и ктото(ее хозяин?) шифрует инфу о именах чтобы их вычислять?
разве про то разговор?
при чем тут TableName (имя таблицы)? когда в примере на который это было отвечено, были имена полей этой таблицы.
приведенный пример показывает, что при четком выполнении условия
> при изменени структуры базы не отвалится клиент. ([12])
при оставлении процедур в там виде в котором они есть, клиент таки "отвалится"...
а ваши "опровержения"(?) [14] вообще ни о чем. типа "в огороде бузина а в Киеве дядько".

> табличка на 2 разбилась, потому что все сложней стало
разработку и релиз не путай... с чего табличке разбиваться на 2 без причины, и не пофигу ли сложней или проще стало при уже работающей (именно с 1 табличкой), сданной в эксплуатацию программе? (а это единственная причина почему клиентская прога уже не меняется)

← →
Petr V. Abramov © (2007-09-16 14:21) [16]

> sniknik © (16.09.07 01:21) [15]
если речь шла о звездочке, тогда отвалится все.
если о том, что по-вашему лишне оборачивать таблицу хранимкой - вот есть 100 форм, в которых используется запрос к TAbleName. При изменении структуры я их что, искать буду?

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

← →
sniknik © (2007-09-16 15:17) [17]

> если речь шла о звездочке
ну о чем же еще? о звездочке, и о вообще нужности процедуры в таком исполнении.

> вот есть 100 форм, в которых используется запрос к TAbleName. При изменении структуры я их что, искать буду?
естественно, если не знаеш где находятся то придется искать. и причем практически в любом случае. будет у тебя не 100 форм, а 100 процедур в которых какимто боком участвует эта таблица (а это будет если в них будет хоть какаято логика с использованием этой таблицы), разве не придется искать и править?

> Если приложение на саппорте и развивается вместе с компанией-заказчиком - все может быть
вот о том и речь, и сколько раз тебе приходилось по заданию сапорта/цто/начальства/клиентов/... кого бы то ни было, менять базу не трогая программу работающую с этой базой?
мне ни разу, а вот наоборот (менять клиентскую прогу по их требованиях) постоянно, и тут если делать все через процедуры менять придется минимум в 2 местах.

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

и было бы изза чего, если бы процедура действительно чтото выполняла, была бы не в 1 запрос, а чтото делала (то что проще сделать на сервере чем в клиентской проге).

← →
Petr V. Abramov © (2007-09-16 21:54) [18]

> будет у тебя не 100 форм, а 100 процедур в которых какимто боком участвует эта таблица
это по dependencies ищется. Если будет 100 процедур - тоже не сильно помогает. А если знать, что клиент не обращается напрямую к таблице никогда а только через вполне понятного названия хранимку (или view), то можно быть уверенным, что надо поправить только хранимку и один раз, а не напрягать мосх знанием того, где на нее референсы в клиенте.

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

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

← →
sniknik © (2007-09-16 22:17) [19]

> на сервере была и будет.
т.е. ты человек потерянный для разумных компромисов. и если логика требует всего лиш запроса то ты его безжалостно перенесешь сервер лиш бы она(логика) стала серверная... :)

> и только потом клиента.
э нет... при чем здесь клиент? ты же ратуешь за логику где "меняешь в базе не трогая клиента", а описываешь ситуацию получается "моего типа" когда изза изменений клиента меняется база... (потом это делается или сначала какая разница?)

> позволяющей не раздувать штат операторов.
а это то тут каким боком?

p.s. я тут вижу начинается плавный переход(/передергивание) от описанных процедур к какимто глобальным действительно чтото выполняющим... надо закругляться, а то объявят еще чего доброго противником процедур вообще...

← →
Petr V. Abramov © (2007-09-17 09:31) [20]

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

← →
sniknik © (2007-09-17 10:52) [21]

> база первична, клиент вторичен. Добавилось поле - надо его на какую-нить форму все-таки добавить.
что за бред? данные живут собственной жизнью?
или к тебе приходит начальник и говорит "а добавь ка ты в базу новое поле. просто так, мне вот захотелось. клиентскую прогу не трогай, там все нормально.".
или он все таки говорит "нужны новые данные в отчёте, добавь" и тут ты думаешь есть ли они у тебя в базе, и если нет то меняешь базу, а после клиента чтобы юзерам их эти новые поля показывать/редактировать.

> Переехало поле в другую таблицу - клиенту это не важно.
часто переезжает? естественно после того как прога сдана, и главное насколько часто этот "переезд" не вызывает изменений клиента. в очередной раз спрашиваю.

и тебе не все ли одно где менять/искать в проге или в процедурах? если оно "переехало" (и процедуры действительно ПРОЦЕДУРЫ, а не то что в примере тут).

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

← →
Petr V. Abramov © (2007-09-17 12:51) [22]

> тут ты думаешь есть ли они у тебя в базе, и если нет то меняешь базу, а
> после клиента чтобы юзерам их эти новые поля показывать/редактировать.
как это противоречит [20]??? какая разница, начальник сказал поле добавить или сказал "хочу чтоб все было клево"

> и тебе не все ли одно где менять/искать в проге или в процедурах?
в процедурах проще, они все "рядом" и ищется по dependenies, сории за троектраное повторение

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

> как это противоречит [20]???
тем что первичен все таки юзер(/программа), именно по его желаниям вносятся изменения в рабочую(законченную) программу (именно программу, юзер вообще может не знать что есть такое база), юзер (через начальника и т.д.) требует изменений в программе с которой он работает а уже это тянет за собой изменения в базе.

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

> в процедурах проще, они все "рядом" и ищется по dependenies
все компоненты тоже рядом, в датамодуле (или в нескольких логически разделённых) ищется в pas, dfm, простым ctrl+f f3
не вижу разницы.

> sniknik © (17.09.07 14:33) [23]
> в датамодуле (или в нескольких логически разделённых) ищется в pas, dfm, простым ctrl+f f3
не вижу разницы.
это хорошо когда модулей сильно меньше 1000
и в любом случае лучше переделывать только хранимки, чем И хранимки, И клиента

> юзер (через начальника и т.д.) требует изменений в программе с которой он работает а уже это тянет за собой изменения в базе.
после чего принимается решение добаваить поле :)

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

> и в любом случае лучше переделывать только хранимки, чем И хранимки, И клиента
о чем твержу с самого начала, только про клиента... изменения которого бывают чаще, лучше менять только клиента, чем клиента + хп. а хранимку менять не придётся если вместо подобного рода хранимок ([5]) будет просто запрос.
и различного рода интерпретаций/обработок одних и тех же данных тоже бывает больше, чем изменений в базе, что потребует изменений только клиента если не следовать "дубовой" логике "все должно быть в процедурах", вот тогда, чтобы всего лишь представить данные по другому придётся менять и базу, добавлять хп. потому как такого, нового варианта там не предусмотрено.
или например для добавленного поля должно быть ограничение выборки (ну нафига все данные?) добавляешь в запросе который в процедуре условие, выводишь это условие в параметр процедуры (а как еще его задавать?)... и тащишься от того, что ничего в клиенте менять не надо. а он рухнул. почему?

> после чего принимается решение добаваить поле :)
т.е. признаешь что программа все таки первична. но прямо сказать стесняешься.

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

p.s. ты так и не дал ответа о том приходилось ли менять структуру базы без изменений работающей с ней клиента. (было что то типа "дофига", что в итоге оказалось "парными" изменениями вместо с клиентом, но только "потом").

p.p.s. насильно научить нельзя. © китайская мудрость.

Удалено модератором

> sniknik

а какие преимущества дает вбивание некоего запроса где-то в CommandText на клиенте по сравнению с вынесением оного в хранимку?

Bless © (17.09.07 16:39) [27]
а какие преимущества дают фразы вылетающие из твоего рта, по сравнению спо маркированными блоками заученными твоим собеседником? так чтобы при разговоре обмениваться метками и сразу становиться ясно что имеется ввиду...

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

по-моему, пора переносить в "прочее" за отсутствием "я правильно проектирую"

> sniknik © (17.09.07 18:09) [28]
>
> Bless © (17.09.07 16:39) [27]
> а какие преимущества дают фразы вылетающие из твоего рта,
> по сравнению спо маркированными блоками заученными твоим
> собеседником? так чтобы при разговоре обмениваться метками
> и сразу становиться ясно что имеется ввиду...
>
> вот примерно такое же. sql это язык общения, когда что то
> говоришь часто, много и это разумно сократить, типа технический
> термин включающий целую технологию, это процедура. но привет
> процедурами говорить... это чересчур (это уже типа "преведа"
> - падонковшина).
> имхо конечно.
>

Иными словами, твое возражение сводится к "не нравится"?

Имхо, проведенная тобой аналогия не очень удачна. Вариантов ответа собеседника в человеческом разговоре - необозримое множество, каждый вариант не промаркируешь. Количество же запросов к базе - величина счетная. Кроме того, с моей точки зрения на твою аналогию, запрос - это вполне себе "типа технический термин" и удобнее "говорить" "дай мне ведомость ГСМ", чем "дай мне select ... from ... inner join ..." :)

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

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

> дай мне ведомость ГСМ
это уже как раз "термин", пусть он не не очень сложный но он логически выделяем. (это и я бы сделал если не процедурой так вьюшкой... возможно)

> чем "дай мне select ... from ... inner join ..." :)
найди inner join в приведённых, обсуждаемых процедурах. ([5])

> лично я стараюсь любой мало-мальски сложный запрос
сложный типа [5]? вот вот...

p.s. не пытайтесь навязать мне роль "противника процедур вообще" pls, моя позиция "процедуры только там где они необходимы", а против я, только того подхода что описал "все без исключения через процедуры". т.к. удобства, имхо, мнимые, а проблем увеличивается.

> Имхо, проведенная тобой аналогия не очень удачна.
другая может более удачная.
средние и тёмные века... алхимик с именем "Клиент" и лаборант с именем "Сервер sql (можно просто Сервер)", алхимик сам работать не любит, заставляет лаборанта, типа "а сделай ка мне любовное зелье!"
"Сервер" зная рецепт зелья берет свежую печень лягушки, помет летучей мыши и т.д.(список ингредиентов) варит, парит перемешивает их и еще как то обрабатывает, в конце отжимает первые 20 капель (первый отжим) в пузырёк (10 оставшихся "зажимает" себе ;), клеит на него лейбел "шанель №5" и подаёт "Клиенту"...
во! вот это процедура! (т.е. рецепт в данном случае = процедуре в нашем)
рецепт может быть и не таким сложным, но он должен все таки чем то выделяться, иметь логическую завершённость, чтобы иметь право зваться рецептом...
если же алхимик просто орёт лаборанту "дай мне жабу вон с того стола, да позеленее!" это просто запрос, и не иначе.
а мне говорят, что это тоже надо сделать процедурой (рецептом) и кричать вместо "дай жабу ..." - "подача лягушки №8" типа удобнее, т.к. если вдруг в комнате случится перестановка(с чего бы?) и и на месте стола появится тумбочка, и аквариум с жабами переедет на неё, то не надо будет менять в языковой конструкции стол на тумбочку, а продолжать орать "подача лягушки №8"...
я же говорю, что перестановки у меня бывают гораздо реже чем потребность в "лягушках" меняется на потребность в "сушенных кузнечиках" например или др. совершенно неожиданное (т.к. не от меня, и даже не от погоды зависит), и если пытаться все эти потребности заформализовать, и на каждый сделать свой рецепт... то и получится то с чем я сталкиваюсь, не первый раз причём, и с чего начал говорить в ветке - на 20 таблиц 10 вьюшек и 40 процедур (ни одна из которых толком ничего не делает... 30 просто показанные "пустышки", и это в программе которая "рабочая, только чего то, ни с того не сего стала подтормаживать, ну и вылетать время от времени..." ).

ну вот, до сих пор непонятно? неважно, это мой последний пост в данной ветке. (какой смысл? если слышат не то, что говоришь, а то что хотят услышать)

> sniknik © (18.09.07 12:05) [31]
> сложный типа [5]? вот вот...

В первом варианте моего ответа были слова "заворачивать запрос вида [5] в хранимку я тоже считаю глупостью". Теперь жалею, что вырезал :)

>
> p.s. не пытайтесь навязать мне роль "противника процедур
> вообще" pls, моя позиция "процедуры только там где они необходимы",
> а против я, только того подхода что описал "все без исключения
> через процедуры". т.к. удобства, имхо, мнимые, а проблем
> увеличивается.
>

Собственно, я тебя понял правильно. Просто показалось, что твое "где они необходимы" сильно меньше, чем мое.
Ведь камни в огород ХП ты начал бросать не со своего, доставшегося тебе по наследству, примера (где с хранимками очевидный перебор), а в ответ на "как средствами SQL заменить любые первые 4 символа в строке и сделать это желательно в XП".
А я как раз могу представить ряд вариантов (ввиду того, что формулировка автора сабжа допускает широкую трактовку того, что именно ему хочется сделать), когда это стоит вынести именно в ХП. Поэтому твоя резко негативная реакция удивила.

Замена символов в строке средствами SQL Найти похожие ветки