Login
sql stored procedure
NEW 10.02.05 21:41
in Antwort Murr 10.02.05 21:21
Теория говорит, что должно иметь место Отсечение...
вот-вот... у меня к нему всегда предубеждение было, во всех языках :)) "а вдруг реализация такая, что не отсечет?" :))))
Например, лепить таблицы и структуру - в ЕМ мне не так удобно.
никогда не лепил в EM "по-крупному" :) Время от времени тока смотрел, как он тот или иной объект заскриптовывает. А так - все ручками...
А потом придет кто-то умный и попросит добавить столбец в таблицу.
тоже бывает часто... но не так, чтоб напрямую. "Умные" - они обычно чаще фичу просят. А как ее на уровне БД разруливать - это уже наше (мое?) дело. А столбы добавлять... Ну, вот надо, к примеру, 1 добавить... и вспоминаю я, что месяц назад мы уже добавляли какой-то столб в той же подсистеме... полнотекстовый поиск по скриптам с репортинговыми вьюхами и хранимками, ищем "старый" столб и рядом с ним вписываем новый :))))))) Ну, утрирую немножко, но бывает и так.
Есть вот еще другой сорт "умных". Это программисты, использующие наш софт. Они, конечно же, все сами лучше всех знают
"Anforderungsliste vom 01.02.2005, Punkt XYZ. Der Report "ABC" braucht ca. 50 Sekunden. Kann man hier vielleicht ein Paar Indizes auf die Tabelle setzen, damit er schneller wird?" Угу, покажи мне еще эту таблицу, хранимку и тормозной участок в коде, посмеемся вместе
--------------
Авиатор х#ев
вот-вот... у меня к нему всегда предубеждение было, во всех языках :)) "а вдруг реализация такая, что не отсечет?" :))))
Например, лепить таблицы и структуру - в ЕМ мне не так удобно.
никогда не лепил в EM "по-крупному" :) Время от времени тока смотрел, как он тот или иной объект заскриптовывает. А так - все ручками...
А потом придет кто-то умный и попросит добавить столбец в таблицу.
тоже бывает часто... но не так, чтоб напрямую. "Умные" - они обычно чаще фичу просят. А как ее на уровне БД разруливать - это уже наше (мое?) дело. А столбы добавлять... Ну, вот надо, к примеру, 1 добавить... и вспоминаю я, что месяц назад мы уже добавляли какой-то столб в той же подсистеме... полнотекстовый поиск по скриптам с репортинговыми вьюхами и хранимками, ищем "старый" столб и рядом с ним вписываем новый :))))))) Ну, утрирую немножко, но бывает и так.
Есть вот еще другой сорт "умных". Это программисты, использующие наш софт. Они, конечно же, все сами лучше всех знают


--------------
Авиатор х#ев
NEW 10.02.05 21:57
in Antwort digital_pilot 10.02.05 21:41
"а вдруг реализация такая, что не отсечет?"
----------------
В продуктах дяди Билли я об этом говорю такЖ
"А вдруг в следующий раз не отсечет!!!"
А так - все ручками...
----------------
Мне быстрее сделать черновик в Аксессе и выдернуть из него скрипт для
MS SQL - есть такая тулузка.
А как ее на уровне БД разруливать - это уже наше (мое?) дело.
---------------
Если сроки не давят - можно и поразруливать, а если давят, то приходится
заранее озаботится тем, чтобы разруливание было максимально простым
и быстрым.
...и вспоминаю я...
...полнотекстовый поиск по скриптам...
---------------
Вот-вот. А как что-то пропустишь? Отсюда и растут ноги у требования об том,
чтобы _все_, что касается одной таблицы (или группы) было в одном файле.
Тагда надо найти и серьезно поправить только ОДИН файл. К тому же он лежит в той же папочке, где и форма с миддле-сервером. С вьюхами
такое, увы, не проходит.
покажи мне еще эту таблицу
--------------
Ихь хабе шпрейхен зи Дойчь нихт. Но в общем случае отдается интерфейсная
часть с полным запретом использовать недокументированные возможности.
Так что Kann man hier vielleicht ein Paar Indizes просто не возникает.
----------------
В продуктах дяди Билли я об этом говорю такЖ
"А вдруг в следующий раз не отсечет!!!"

А так - все ручками...
----------------
Мне быстрее сделать черновик в Аксессе и выдернуть из него скрипт для
MS SQL - есть такая тулузка.
А как ее на уровне БД разруливать - это уже наше (мое?) дело.
---------------
Если сроки не давят - можно и поразруливать, а если давят, то приходится
заранее озаботится тем, чтобы разруливание было максимально простым
и быстрым.

...и вспоминаю я...
...полнотекстовый поиск по скриптам...
---------------
Вот-вот. А как что-то пропустишь? Отсюда и растут ноги у требования об том,
чтобы _все_, что касается одной таблицы (или группы) было в одном файле.
Тагда надо найти и серьезно поправить только ОДИН файл. К тому же он лежит в той же папочке, где и форма с миддле-сервером. С вьюхами
такое, увы, не проходит.

покажи мне еще эту таблицу
--------------
Ихь хабе шпрейхен зи Дойчь нихт. Но в общем случае отдается интерфейсная
часть с полным запретом использовать недокументированные возможности.
Так что Kann man hier vielleicht ein Paar Indizes просто не возникает.

NEW 10.02.05 22:13
in Antwort Murr 10.02.05 21:57, Zuletzt geändert 10.02.05 22:14 (digital_pilot)
что касается одной таблицы (или группы) было в одном файле
о, не... у меня об этом и мечтать не приходится :) бизнес-логика все интенсивнее выносится на сервер, хранимки хоть и группирую по подсистемам, но по таблицам все сгруппировать невозможно. Впрочем, трагедии у меня тут особой и не возникает.
Ихь хабе шпрейхен зи Дойчь нихт.
ну, товарисч жалуется на медленный репорт и предлагает-просит "повесить индекс на табличку, чтоб было быстрее". Ну да, ему ж коллеги из IT сказали, что "если повесить индекс, то все будет круто и быстро"
Но в общем случае отдается интерфейсная
часть с полным запретом использовать недокументированные возможности.
угу... а у нас еще и серверная часть отдается. Но ее напрямую, в обход клиентской интерморды, мало кто пока использует.
--------------
Авиатор х#ев
о, не... у меня об этом и мечтать не приходится :) бизнес-логика все интенсивнее выносится на сервер, хранимки хоть и группирую по подсистемам, но по таблицам все сгруппировать невозможно. Впрочем, трагедии у меня тут особой и не возникает.
Ихь хабе шпрейхен зи Дойчь нихт.
ну, товарисч жалуется на медленный репорт и предлагает-просит "повесить индекс на табличку, чтоб было быстрее". Ну да, ему ж коллеги из IT сказали, что "если повесить индекс, то все будет круто и быстро"

Но в общем случае отдается интерфейсная
часть с полным запретом использовать недокументированные возможности.
угу... а у нас еще и серверная часть отдается. Но ее напрямую, в обход клиентской интерморды, мало кто пока использует.
--------------
Авиатор х#ев
NEW 10.02.05 22:36
in Antwort digital_pilot 10.02.05 22:13
но по таблицам все сгруппировать невозможно
------------------
Теперь оцени - в процедурах нет Join'ов. Вместо них вызывается другая
процедура.
бизнес-логика все интенсивнее выносится на сервер
------------------
Есть такая тенденция. Считается, что можно менять архитектуру базы и
апп-сервера, не меняя клиента. Пока особых преимуществ не вижу - все
что нужно можно написать на любом из языков, но чем более плоской
выглядит база для апп-сервера, а апп-сервер для клиента - тем лучше.
Но ее напрямую...
----------------
В этом месте я начинаю жалеть, что нет триггеров на select'ы
------------------
Теперь оцени - в процедурах нет Join'ов. Вместо них вызывается другая
процедура.

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

NEW 10.02.05 22:53
in Antwort Murr 10.02.05 22:36
Теперь оцени - в процедурах нет Join'ов.
а в бизнес-логичных их и нету почти... там все больше ножницами (insert/update) таблицы кромсать приходится :)
Есть такая тенденция. Считается, что можно менять архитектуру базы и
апп-сервера, не меняя клиента. Пока особых преимуществ не вижу - все
а у нас нету миддл-тиера :) вернее, исторически было некое его огрызочное подобие + огромная часть бизнес-логики на клиенте. Вообще (опять же, в наших условиях) особого смысла в 3-х-звенке не вижу.
Мало того, не без моего влияния стали активно вырезать бизнес-логику из клиента и переливать непосредственно на сиквел-сервер в хранимки и триггеры. Преимущества дали о себе знать буквально через месяц. Кодирование, деплоймент и суппорт заметно упростились.
--------------
Авиатор х#ев
а в бизнес-логичных их и нету почти... там все больше ножницами (insert/update) таблицы кромсать приходится :)
Есть такая тенденция. Считается, что можно менять архитектуру базы и
апп-сервера, не меняя клиента. Пока особых преимуществ не вижу - все
а у нас нету миддл-тиера :) вернее, исторически было некое его огрызочное подобие + огромная часть бизнес-логики на клиенте. Вообще (опять же, в наших условиях) особого смысла в 3-х-звенке не вижу.
Мало того, не без моего влияния стали активно вырезать бизнес-логику из клиента и переливать непосредственно на сиквел-сервер в хранимки и триггеры. Преимущества дали о себе знать буквально через месяц. Кодирование, деплоймент и суппорт заметно упростились.
--------------
Авиатор х#ев
NEW 11.02.05 02:41
in Antwort digital_pilot 10.02.05 22:53
...особого смысла в 3-х-звенке не вижу.
Кодирование, деплоймент и суппорт...
------------------
Я тоже не видел, пока не начал делать. Эффект, примерно такой же, как
и при переносе кода в процедуры. Единственный недостаток - кода все же
получается чуть больше, но сам код - проще и понятней.
Кодирование, деплоймент и суппорт...
------------------
Я тоже не видел, пока не начал делать. Эффект, примерно такой же, как
и при переносе кода в процедуры. Единственный недостаток - кода все же
получается чуть больше, но сам код - проще и понятней.
13.02.05 17:56
in Antwort Fleischmann 09.02.05 17:01
А почему бы не так?
create procedure get_count
@text_value varchar(50)
as
if @text_value is null
select count(id) from mf_type where text_value is null
else
select count(id) from mf_type where text_value = @text_value
veni, vidi... expuli