>> и какие же есть коммерческие российские субд уровня оракла или сиквела? поведайте хех
>Сейчас все стремятся в опенсоурс даже большие компании… > И з коммерческих есть Линтер… > Честно, скажу не крутил его, но сталкивался с их коммерсами на одной из сходок… Судя по рекламным буклетам и рассказам уровень очень высокий… Как раз на уровне сиквела… При этом большая поддержка осей… с Сиквелом не сравнить… До оракла дб и ASE не дотягивают только из-за отсутствия кластера… Но он тольуо у этих двух СУБД и есть… Весч сильно дорогая и применяется в экзотических задачах…
может где-то они и есть, но то что предлагали из серьезного как-то или на оракле или сиквеле базируется.
> > Йащур (Йащур) писал (а) в ответ на сообщение:
>> угу файрбирд бггг
>А чем тебе RedDB (онже фаерберд, онже интербайз) не нравятся… Интербэйз широко использовался, а может и сейчас используется в Боинге… Как раз в процессе тестирования… В него каждую наносекунду с датчиков поступала инфа и тут же обрабатывалась…
у нас есть на нем сидящая система написания техпроцессов и иже с ними. «Спрут» мне не понравилось. ну может субъективно, но тот же сиквел как-то ближе. может просто лучше знаю.
>> поймите простую вещь — если у нас на производстве не могут стантартизировать свои процессы это не проблема ПО
> > Йащур (Йащур) писал (а) в ответ на сообщение:
>> а это все часть культуры производства если чо. организация бизнес процессов в модных терминах. и если нам прозрачные стабильные процессы не нужны это тоже показатель нашего уровня в этой самой «культуре производства».
> Вот тут не прав в корне… Поверь моему опыту анализа бизнес процессов и внедрении именно отраслевых решений… > Большие игроки (1Ц, САП, Оракл, МС, итд). Очень ленивы… И их работа строится в натягивании совы на глобус производства на свою систему… Это неправильно вкорне… ПО должно работать по правилам производства, а не производство по правилам ПО!
не, не так. производство должно работать по правилам и эти правила не должны меняться патамучта левая нога начальнега производства в данный момент этого захотела. вот тогда и ПО с ним дружить будет, а что хочет нога начальнега ПО разумеется не ведает
> Так что тут ты не прав! Любой процесс можно описать, какой бы хреновый он бы небыл!
хех кто ж спорит, что любой процесс можно формализировать. проблема в другой плоскости — процесс может легко поменяться после того, как ты его опишешь.
>> и какие же есть коммерческие российские субд уровня оракла или сиквела? поведайте хех
>СУБД уровня оракла есть только у оракла > СУБД из реестра российских, которые можно применять по 118-ФЗ: > 1. «Ред База Данных» > 2. ЛИНТЕР
> 3. Postgres Pro > 4. «CronosPRO» > Насколько хороши — не знаю, не работал. Но, наверняка, все сильно недотягивают до оракла. И MS SQL Server не дотягивает, но на нем много чего сделано и работает. И на PostgreSQL можно сделать и будет работать, если с умом. Для того, что сделать хорошо нельзя и слишком сложно — останется оракл.
никогда к стыду своему о таких не слышал. в оправдание могу сказать, что все же не разработчик ерп, а потребитель
> Про ТУКи — не могу сказать, нужны они вашему пр-ву или нет. Вы точно уверены, что не нужны?
вы не понимаете — ТУК это жизненная необходимость. чтоб было понятно — если у вас точится штырь из прутка и в ТП указан исходный материал пруток диаметром 12 мм, то когда к вам приезжает пруток 15-мм вам придется написать этот самый ТУК и перекинуть его токарю. а потом придет 14-мм и снова ТУК. А если у вас кончиличь резцы, опять же прописанные в ТП, но есть другие, но с другим режимом резания вам снова придется писать этот самый ТУК. и это простейшие примеры. я тут уже говорил — технологи на производстве самые нищасные люди
> Если серийное потоковое пр-во — то не должны быть нужны. Если мелкосерийное с ручной сборкой и кучей модификаций — то, наверное, TDMS не надо было внедрять.
серийное. что совершенно не избавляет от необходимости внесения изменения в техпроцессы. помницо пару тройку лет назад и нас и Климова колбасило, когда где-то в Сибири обанкротился заводег. мы у них пружинку покупали одну. та исчо была эпопея.
> Уверяю вас, если ваше руководство кинет клич на команду IT-шников с ЗП как в силиконовой долине (даже ниже, но сравнимо) — у нас в России нашлись бы нужные специалисты и сделали бы все как надо
бгг да вроде внедренцам из 1С завод неплохо отстегивает. но 10 лет. и процесс продолжается
> Да я же и не утверждаю, что у нас все здорово и везде самые современные производства. Скорее наоборот. Куча советского наследия без модернизации долгие годы, часть — развалено, разворовано, занято мелкими частниками… > Но есть и другие примеры. > В штатах — в целом промышленность более развита, с этим никто в здравом уме спорить не будет. Но и у них есть знатные просеры, как пример — в атомной отрасли. И мегапопилы.
блин, вот дались вам эти штаты… как бы там хреново не было, но это мы у них оборудование и технологии покупаем, а не наоборот.
> > У вас с шизлом просто точка зрения такая, что мы ущербные и нихрена ничего не можем и везде отстаем и никогда ни в чем не будем конкурентны. А на западе — непогрешимые эльфы. Это не так. ВПК и РОСАТОМ часто (не всегда) являются примером обратного.
хех у меня точка зрения такая, что прежде, чем хаять сделанное кем-то неплохо было бы сделать нечто подобное самим. с этим есть проблемы
21:13 18.11.2017
Йащур (Йащур) писал (а) в ответ на :
> может где-то они и есть, но то что предлагали из серьезного как-то или на оракле или сиквеле базируется.
Рынок мать его! Опять же есть ERP, у каждого своя БД… Йащур (Йащур) писал (а) в ответ на :
> у нас есть на нем сидящая система написания техпроцессов и иже с ними. «Спрут» > мне не понравилось. ну может субъективно, но тот же сиквел как-то ближе. может просто лучше знаю.
А что именно не понравилось? Среда администрирования? Кстати интербайз — это версионник… А сиквел — блокировочник… А у них принцип работы с «конкуренси контрол» абсолютно разный.
Йащур (Йащур) писал (а) в ответ на :
> не, не так. производство должно работать по правилам и эти правила не должны меняться патамучта левая нога начальнега производства в данный момент этого захотела. > вот тогда и ПО с ним дружить будет, а что хочет нога начальнега ПО разумеется не ведает
Ну тут ты утрируешь? Пример можно, такого кардинального изменения процесса… Мне в такое вериться с трудом…
Йащур (Йащур) писал (а) в ответ на :
> хех кто ж спорит, что любой процесс можно формализировать. проблема в другой плоскости — процесс может легко поменяться после того, как ты его опишешь.
Да, конечно же… Но не координально! Во избежание этого должна быть гибкость ПО… Модульность и прочее… Я даже натыкался на другое… Звонит мне клиент и говорит… -ут у нас чтока такая, тяжело кое что проходит… Не совсем удобно в использовании… -А помнишь запару 3 года назад… так вот эта фича сделана как раз для предотвращения таких щзапар… -Так это 3 года назад было, и вообще очень редкий случай… -Гавно-вопрос… Могу отключить и пустить по короткому пути, но если у тебя такая запара повториться, раскручивать ее будите сами или я возьму копейку с тебя как за новый функционал, за возврат в систему этой фичи! -Не, тогда мы будем работать дальше… Это и есть гибкость ПО. Но иногда такая гибкость приводит вот к таким вот неудобствам… Как ты любишь говорить компромисс — мать его! Но гибкое ПО всем делать лень, это трудно и затратно, плюс надо вникать и иметь опыт в отрасли… Поэтому строго заточенные отраслевые решения и побеждают над большими ERP.
21:16 18.11.2017
Йащур (Йащур) писал (а) в ответ на :
> хех у меня точка зрения такая, что прежде, чем хаять сделанное кем-то неплохо было бы сделать нечто подобное самим. с этим есть проблемы
Помнишь я тебе рассказывал в предыдущем посте про складские проводки… Мы сделали алгоритм не зависимый от количества данных… Работает на любом количестве за 800 милисекунд! И ненадо тяжелых заплаток… А всего то надо было… не, не скажу — секрет фирмы!
21:18 18.11.2017
Йащур (Йащур) писал (а) в ответ на :
> бгг да вроде внедренцам из 1С завод неплохо отстегивает. но 10 лет. и процесс продолжается
Я расскажу тебе что у вас происходит, нахавался этого с гору… но не сейчас… Накрутил сегодня 200 км на машине с семьей…. Устал… Завтра напишу!
22:32 18.11.2017
_developer (_developer) писал (а) в ответ на :
> Йащур (Йащур) писал (а) в ответ на сообщение:
>> может где-то они и есть, но то что предлагали из серьезного как-то или на оракле или сиквеле базируется.
>Рынок мать его! > Опять же есть ERP, у каждого своя БД…
ну дык мы ж рыночная страна, и как-то посконных субд особо не наблюдается
>> у нас есть на нем сидящая система написания техпроцессов и иже с ними. «Спрут»
>> мне не понравилось. ну может субъективно, но тот же сиквел как-то ближе. может просто лучше знаю.
>А что именно не понравилось? Среда администрирования? > Кстати интербайз — это версионник… А сиквел — блокировочник… > А у них принцип работы с «конкуренси контрол» абсолютно разный.
да я лет 6−7 назад катался в Бауманку на две недели, у них покупали и они типо обучали, щаз уже не очень помню. с хранимыми процедурами и триггерами какие то траблы были. хотя тогда 2.1 вроде версия была, щас уже 2.5 может что-то и изменилось.
> > Йащур (Йащур) писал (а) в ответ на сообщение:
>> не, не так. производство должно работать по правилам и эти правила не должны меняться патамучта левая нога начальнега производства в данный момент этого захотела. >> вот тогда и ПО с ним дружить будет, а что хочет нога начальнега ПО разумеется не ведает
>Ну тут ты утрируешь? Пример можно, такого кардинального изменения процесса… Мне в такое вериться с трудом…
утрирую конечно, но не сильно. скажем можно одно производство разделить на два самолетное и вертолетное, естественно самостоятельные со своими администрациями и прочим. но это глобально. а может какой нить инициативный прыщег придумать свою систему кодирования о которой, когда внедрялась система никто не ведал хех и не пошлешь прыщега, он какойто родственник генерала я стараюсь от всего этого подальше держаться, но могу поспрошать у тех кто непосредственно связан. в то же время есь у нас система на оракле, старенькая, еще под полуосью, из середины 90-х. вот туда никто не лезет с радикальными идеями, страшно — если рухнет всему пипец. и ##### работает исправно уже больше 20-ти лет
>> хех кто ж спорит, что любой процесс можно формализировать. проблема в другой плоскости — процесс может легко поменяться после того, как ты его опишешь.
>Да, конечно же… Но не координально! > Во избежание этого должна быть гибкость ПО… Модульность и прочее… > Я даже натыкался на другое… Звонит мне клиент и говорит… > -ут у нас чтока такая, тяжело кое что проходит… Не совсем удобно в использовании… > -А помнишь запару 3 года назад… так вот эта фича сделана как раз для предотвращения таких щзапар… > -Так это 3 года назад было, и вообще очень редкий случай… > -Гавно-вопрос… Могу отключить и пустить по короткому пути, но если у тебя такая запара повториться, раскручивать ее будите сами или я возьму копейку с тебя как за новый функционал, за возврат в систему этой фичи!
> -Не, тогда мы будем работать дальше… > Это и есть гибкость ПО. Но иногда такая гибкость приводит вот к таким вот неудобствам… Как ты любишь говорить компромисс — мать его! > Но гибкое ПО всем делать лень, это трудно и затратно, плюс надо вникать и иметь опыт в отрасли… Поэтому строго заточенные отраслевые решения и побеждают над большими ERP.
хех да я ваще сторонник самописной системы силами заводских айтишнегов, благо они есть, и опыт внедрения 1С только подкрепляет в этом мнении оно может и не такое красивое получалось, но прозрачное и гибкое. но что имеем то нас и имеет
22:38 18.11.2017
_developer (_developer) писал (а) в ответ на :
> Йащур (Йащур) писал (а) в ответ на сообщение:
>> хех у меня точка зрения такая, что прежде, чем хаять сделанное кем-то неплохо было бы сделать нечто подобное самим. с этим есть проблемы
>Помнишь я тебе рассказывал в предыдущем посте про складские проводки… Мы сделали алгоритм не зависимый от количества данных… Работает на любом количестве за 800 милисекунд! И ненадо тяжелых заплаток… А всего то надо было… не, не скажу — секрет фирмы!
молодцы чо видишь ли, я к отечественным программерам претензий не имею, сам имел к ним отношение… о, анек вспомнился в тему — девушка, вы наверное программист? — да, а как вы догадались? — это же очевидно — у всех программистов такое глупое выражение лица — сам дурак! — да, я тоже программист…
но как ты писал выше рынок, и на этом рынке доминируют продукты с запада.
23:00 18.11.2017
Йащур (Йащур) писал (а) в ответ на :
> ну дык мы ж рыночная страна, и как-то посконных субд особо не наблюдается
Йащур (Йащур) писал (а) в ответ на :
> но как ты писал выше рынок, и на этом рынке доминируют продукты с запада.
Ну не будь Шизлом!!!! Мы же уже с тобой это обсуждали, когда с суперджет балакали… Рынок и технологичность это разные вещи… И успех на рынке зависит от множества вещей, при этом технологичность стоит на 101 месте! Йащур (Йащур) писал (а) в ответ на :
> да я лет 6−7 назад катался в Бауманку на две недели, у них покупали и они типо обучали, щаз уже не очень помню. с хранимыми процедурами и триггерами какие то траблы были. хотя тогда 2.1 вроде версия была, щас уже 2.5 может что-то и изменилось.
хех. В оракл дб — хранимки появились позже чем в интербэйзе… Я с ним работал давно, по первости… Во времена когда еще рулил Борланд и был Делфи… Уже лет 10 его не юзал… Про хранимки не помню, не юзал их в то время… А вот триггеры- куда без них… Траблов особых вроде не заметил… Баги есть везде, концептуальные промахи совсем другое! Кстати сейчас дурным тоном считается использовать и хранимки и триггеры! Йащур (Йащур) писал (а) в ответ на :
> а может какой нить инициативный прыщег придумать свою систему кодирования о которой, когда внедрялась система никто не ведал хех и не пошлешь прыщега, он какойто родственник генерала
Это часности… Такого навоза хватает везде… Но у меня есть пилюля для такого!
Йащур (Йащур) писал (а) в ответ на :
> в то же время есь у нас система на оракле, старенькая, еще под полуосью, из середины 90-х. вот туда никто не лезет с радикальными идеями, страшно — если рухнет всему пипец. и ##### работает исправно уже больше 20-ти лет
Ха, я систему на клареоне как-то менял на свою… Работала с 92 года… под ДОС еще… тоже 20 лет отпахала… Но уже не вывозила современных тенденций… Основной запарой было именно интеграция с другими системами… Йащур (Йащур) писал (а) в ответ на :
> хех да я ваще сторонник самописной системы силами заводских айтишнегов, благо они есть, и опыт внедрения 1С только подкрепляет в этом мнении > оно может и не такое красивое получалось, но прозрачное и гибкое. но что имеем то нас и имеет
Кстати, видел у одной компании собственную разработку, которая потом переросла в корпоративную систему… То есть она была на столько крута, что ее распространили на весь холдинг… А ходдинг там пипец какой… На уровне нашего ГазМяса… И такое бывает! Но манагеры принимающие решения от такого стараются избавляться… Со своих программеров откат не поимеешь! Так что я тебе рассказал — это больше исключение чем правило!
>> ну дык мы ж рыночная страна, и как-то посконных субд особо не наблюдается
> > Йащур (Йащур) писал (а) в ответ на сообщение:
>> но как ты писал выше рынок, и на этом рынке доминируют продукты с запада.
>
> Ну не будь Шизлом!!!! > Мы же уже с тобой это обсуждали, когда с суперджет балакали… > Рынок и технологичность это разные вещи… И успех на рынке зависит от множества вещей, при этом технологичность стоит на 101 месте!
можно написать по этому поводу миллион строк, замутить срач не на одну неделю, но лень это просто констатация имеющего место быть.
> Йащур (Йащур) писал (а) в ответ на сообщение:
>> да я лет 6−7 назад катался в Бауманку на две недели, у них покупали и они типо обучали, щаз уже не очень помню. с хранимыми процедурами и триггерами какие то траблы были. хотя тогда 2.1 вроде версия была, щас уже 2.5 может что-то и изменилось.
>хех. В оракл дб — хранимки появились позже чем в интербэйзе… > Я с ним работал давно, по первости… Во времена когда еще рулил Борланд и был Делфи… Уже лет 10 его не юзал… Про хранимки не помню, не юзал их в то время… А вот триггеры- куда без них… Траблов особых вроде не заметил… Баги есть везде, концептуальные промахи совсем другое!
честно не помню конкретно, но хранимок и триггеров в том что покупали не было. спрашивал почему, но что ответили уже не помню.
> Кстати сейчас дурным тоном считается использовать и хранимки и триггеры!
да? и почему? когда этим занимался нравилось, старался как можно больше логики на них реализовывать. для лентяев типа меня удобно — в одном месте поменял и вуаля все счастливы ни перекомпилировать не надо, ни тем паче с обновлением клиентов возицо…
> Йащур (Йащур) писал (а) в ответ на сообщение:
>> а может какой нить инициативный прыщег придумать свою систему кодирования о которой, когда внедрялась система никто не ведал хех и не пошлешь прыщега, он какойто родственник генерала
>Это часности… Такого навоза хватает везде… Но у меня есть пилюля для такого!
дык само наличие такого прыщега и его положение говорит о той самой культуре производства, которая по вашему мнению тут ни при чем мне сложно представить ситуацию когда тот же Локхид меняет поставщика только потому что коммерческому стало скучно и он решил показать своим олухам как надо работать. и это реальность. прецеденты были
> > > Йащур (Йащур) писал (а) в ответ на сообщение:
>> в то же время есь у нас система на оракле, старенькая, еще под полуосью, из середины 90-х. вот туда никто не лезет с радикальными идеями, страшно — если рухнет всему пипец. и ##### работает исправно уже больше 20-ти лет
>Ха, я систему на клареоне как-то менял на свою… Работала с 92 года… под ДОС еще… тоже 20 лет отпахала… Но уже не вывозила современных тенденций… Основной запарой было именно интеграция с другими системами…
никаких проблем — оно просто не интегрируется. перегонку текстовых файлов туда сюда интеграцией не считаем
> Йащур (Йащур) писал (а) в ответ на сообщение:
>> хех да я ваще сторонник самописной системы силами заводских айтишнегов, благо они есть, и опыт внедрения 1С только подкрепляет в этом мнении >> оно может и не такое красивое получалось, но прозрачное и гибкое. но что имеем то нас и имеет
>Кстати, видел у одной компании собственную разработку, которая потом переросла в корпоративную систему… То есть она была на столько крута, что ее распространили на весь холдинг… А ходдинг там пипец какой… На уровне нашего ГазМяса… И такое бывает! > Но манагеры принимающие решения от такого стараются избавляться… Со своих программеров откат не поимеешь! Так что я тебе рассказал — это больше исключение чем правило!
про откаты я знаю ну не в том смысле, что участвую, но некоторое представление имею… злые йазыки о 25% говорят, но надеюсь врут
23:52 18.11.2017
Йащур (Йащур) писал (а) в ответ на :
> да? и почему? когда этим занимался нравилось, старался как можно больше логики на них реализовывать. для лентяев типа меня удобно — в одном месте поменял и вуаля все счастливы ни перекомпилировать не надо, ни тем паче с обновлением клиентов возицо…
Хранимка и триггер — практически одно и тоже… разница только в вызове… Одну инициирует сам юзер вторая инициируется запросом юзера, что не особо важно для бизнес-логики. Но обе призваны поддерживать бизнес-логику. Поэтому либо пишут хранимки запихивая в нее всю логику, либо пишут логику в триггерах и оперируют только запросами… Использовать и то и то можно, но это «индусский код»…
Йащур (Йащур) писал (а) в ответ на :
> дык само наличие такого прыщега и его положение говорит о той самой культуре производства, которая по вашему мнению тут ни при чем мне сложно представить ситуацию когда тот же Локхид меняет поставщика только потому что коммерческому стало скучно и он решил показать своим олухам как надо работать. и это реальность. прецеденты были
Ой, да я тебя умоляю… Там что не люди работают! Все тоже самое… Неделю назад вернулся из Редмонда… Все тоже самое! Или ты искренне веришь что там бескорыстные и непорочные марсиане работаю!
Йащур (Йащур) писал (а) в ответ на :
> никаких проблем — оно просто не интегрируется. перегонку текстовых файлов туда сюда интеграцией не считаем
Ну не скажи… К кларионовскому ТопСпиду даже через ODBC можно приконнектиться… если не путаю… Мы просто агента писали, что для связи использовали уже не помню… толи что-то нативное, толи ODBC. Йащур (Йащур) писал (а) в ответ на :
> про откаты я знаю ну не в том смысле, что участвую, но некоторое представление имею… злые йазыки о 25% говорят, но надеюсь врут
ОГО! Врут наверное… Стандарт 10%… Особо охреневшие 12% берут!
00:20 19.11.2017
_developer (_developer) писал (а) в ответ на :
> Хранимка и триггер — практически одно и тоже… разница только в вызове… Одну инициирует сам юзер вторая инициируется запросом юзера, что не особо важно для бизнес-логики.
спасибо КЭП
> Но обе призваны поддерживать бизнес-логику. Поэтому либо пишут хранимки запихивая в нее всю логику, либо пишут логику в триггерах и оперируют только запросами… Использовать и то и то можно, но это «индусский код»…
но когда я пишу триггер, я как бы не знаю, кто и как, из каких клиентов будет юзать данную таблицу, мне это и не надо. достаточно знать условия при которых таблица может редактироваться. ну или логику. т. е. не надо одно и то же переписывать в нескольких ХП. когда ты пишешь законченное приложение под заказ ты уверен, что дописывать его никто не будет. но у нас несколько иные условия — завтра может возникнуть новая задача в которой понадобиться редактировать таблицу, но логика редактирования уже сидит в триггере. и разработчику новой задачи не надо над ней голову ломать, он в принципе о ней может ваще не париться, и мне проще если логика меняется переписать триггер, чем вспоминать в каких хранимках редактировалась таблица, причем не все из них мог я писать, могли и другие. вопчем пока не убедил.
> > Йащур (Йащур) писал (а) в ответ на сообщение:
>> дык само наличие такого прыщега и его положение говорит о той самой культуре производства, которая по вашему мнению тут ни при чем мне сложно представить ситуацию когда тот же Локхид меняет поставщика только потому что коммерческому стало скучно и он решил показать своим олухам как надо работать. и это реальность. прецеденты были
>Ой, да я тебя умоляю… Там что не люди работают! Все тоже самое… Неделю назад вернулся из Редмонда… Все тоже самое! > Или ты искренне веришь что там бескорыстные и непорочные марсиане работаю!
не был в Редмонде, так что кто там работает не знаю. но кто работает у нас знаю хорошо дело ведь не в корысти, коммерческий он ведь сын генерального, воровать у самого себя ему смысла нет. просто человек такой, на языке родных осин — самодур
> > Йащур (Йащур) писал (а) в ответ на сообщение:
>> никаких проблем — оно просто не интегрируется. перегонку текстовых файлов туда сюда интеграцией не считаем
>Ну не скажи… К кларионовскому ТопСпиду даже через ODBC можно приконнектиться… если не путаю… Мы просто агента писали, что для связи использовали уже не помню… толи что-то нативное, толи ODBC.
к нашему ораклу через ODBC не прицепицо. только екстовые файлы туда сюда.
> Йащур (Йащур) писал (а) в ответ на сообщение:
>> про откаты я знаю ну не в том смысле, что участвую, но некоторое представление имею… злые йазыки о 25% говорят, но надеюсь врут
>ОГО! Врут наверное… Стандарт 10%… Особо охреневшие 12% берут!
вот мне тоже думается что 25 перебор, врут завистнеги
00:38 19.11.2017
Йащур (Йащур) писал (а) в ответ на :
> к нашему ораклу через ODBC не прицепицо. только екстовые файлы туда сюда.
да ну… А приложение через что работает, тоже через текстовые файлы? Йащур (Йащур) писал (а) в ответ на :
> но когда я пишу триггер, я как бы не знаю, кто и как, из каких клиентов будет юзать данную таблицу,
В том то и дело… приложение таблицы не юзает… Юзеры даже не имеют доступа к ним, только через хранимку… Йащур (Йащур) писал (а) в ответ на :
> завтра может возникнуть новая задача в которой понадобиться редактировать таблицу, но логика редактирования уже сидит в триггере.
если под редактированием таблицы ты имеешь ввиду DML, а не редактирование метаданных (структуры таблицы), то подход не верный… Твоя хранимка должна отражать некую часть процесса или бизнес логики… Как правило процедура не переписывается из-за DML и не зависит от данных которые попадают в таблицу или редактируются…. Другое дело если меняется сама структура таблицы… То да и хранимку надо переписывать… Допустим у меня есть некая таблица с шапкой документа… У нее есть процедура ее создания (добавления записи)… Все… Если кто-то хочет в эту таблицу положить… юзает эту процедуру… Можно конечно часть логики вынести в триггер, но зачем? То есть два подхода юзаем процедуры либо юзаем DML и триггеры! Но вместе — индусский код!
Йащур (Йащур) писал (а) в ответ на :
> не был в Редмонде, так что кто там работает не знаю. но кто работает у нас знаю хорошо
Поверь, все тоже самое… и откаты и кумовство и любовницы с окладом больше ведущих инженеров… итд…
01:24 19.11.2017
_developer (_developer) писал (а) в ответ на :
> Йащур (Йащур) писал (а) в ответ на сообщение:
>> к нашему ораклу через ODBC не прицепицо. только екстовые файлы туда сюда.
>да ну… А приложение через что работает, тоже через текстовые файлы?
по сути да. клиенты скрипты на сиквеле, простые текстовые файлы и оракловский компонент их пережевывающий.
> Йащур (Йащур) писал (а) в ответ на сообщение:
>> но когда я пишу триггер, я как бы не знаю, кто и как, из каких клиентов будет юзать данную таблицу,
>В том то и дело… приложение таблицы не юзает… Юзеры даже не имеют доступа к ним, только через хранимку…
кто сказал? не каждая задача требует еще и сервера приложений. ты пойми все это рождалось в течении пары десятков лет.
> Йащур (Йащур) писал (а) в ответ на сообщение:
>> завтра может возникнуть новая задача в которой понадобиться редактировать таблицу, но логика редактирования уже сидит в триггере.
>если под редактированием таблицы ты имеешь ввиду DML, а не редактирование метаданных (структуры таблицы), то подход не верный… Твоя хранимка должна отражать некую часть процесса или бизнес логики… Как правило процедура не переписывается из-за DML и не зависит от данных которые попадают в таблицу или редактируются…. Другое дело если меняется сама структура таблицы… То да и хранимку надо переписывать… > Допустим у меня есть некая таблица с шапкой документа… У нее есть процедура ее создания (добавления записи)… Все… Если кто-то хочет в эту таблицу положить… юзает эту процедуру… Можно конечно часть логики вынести в триггер, но зачем? > То есть два подхода юзаем процедуры либо юзаем DML и триггеры! Но вместе — индусский код!
ты смотришь с позиции, когда тебе известна конечная цель прописанная в тз и согласованная с заказчиком. я говорю о ситуации, когда конечная цель в тумане. система создается годами. разными разработчиками. я пришел на завод в 2001, она уже создавалась, сегодня из тех кто стоял у истоков не все в живых даже, и создается до сих пор. решается частная задача, и на ее основе движемся дальше, решаем следующую и т. д. и когда для решения некой частной задачи мне нужна какая то таблица, то я не знаю кому и для чего она понадобится через пять лет. но логику обработки данных знаю и прописываю ее в триггерах. и те кто будет использовать эту таблицу дальше о логике могут не париться, просто редактировать. если выйдут из условий триггер остановит их потуги. как-то так. кстати, ХП реально скорость обработки повышают, в чем смысл от них отказываться?
01:32 19.11.2017
Йащур (Йащур) писал (а) в ответ на :
> кто сказал? не каждая задача требует еще и сервера приложений.
та это я про себя говорю, мы работаем именно так через зхранимки без триггеров… Йащур (Йащур) писал (а) в ответ на :
> ты смотришь с позиции, когда тебе известна конечная цель прописанная в тз и согласованная с заказчиком. > я говорю о ситуации, когда конечная цель в тумане. система создается годами. разными разработчиками. я пришел на завод в 2001, она уже создавалась, сегодня из тех кто стоял у истоков не все в живых даже, и создается до сих пор. решается частная задача, и на ее основе движемся дальше, решаем следующую <nobr>и т. д.</nobr> и когда для решения некой частной задачи мне нужна какая то таблица, то я не знаю кому и для чего она понадобится через пять лет. но логику обработки данных знаю и прописываю ее в триггерах. и те кто будет использовать эту таблицу дальше о логике могут не париться, просто редактировать. если выйдут из условий триггер остановит их потуги.
ну както все у вас запутано… не по феншую!!!
Йащур (Йащур) писал (а) в ответ на :
> кстати, ХП реально скорость обработки повышают, в чем смысл от них отказываться?
Каким макаром они скорость повышают? Ты про кеширование планов?
Йащур (Йащур) писал (а) в ответ на :
> по сути да. клиенты скрипты на сиквеле, простые текстовые файлы и оракловский компонент их пережевывающий.
Это какой же версии у вас Оракл, что даже ODBC не понимает? А API компонента, че нет? Как то приложение через него работает, кто то же его писал...
02:00 19.11.2017
_developer (_developer) писал (а) в ответ на :
> Йащур (Йащур) писал (а) в ответ на сообщение:
>> кто сказал? не каждая задача требует еще и сервера приложений.
>та это я про себя говорю, мы работаем именно так через > зхранимки без триггеров…
ну я тоже стараюсь, через хранимки и народ долго к этому принуждал, но и от триггеров не отказываюсь. я так понял по тексту, что ты против того, чтобы клиент напрямую с субд работал.
> Йащур (Йащур) писал (а) в ответ на сообщение:
>> ты смотришь с позиции, когда тебе известна конечная цель прописанная в тз и согласованная с заказчиком. >> я говорю о ситуации, когда конечная цель в тумане. система создается годами. разными разработчиками. я пришел на завод в 2001, она уже создавалась, сегодня из тех кто стоял у истоков не все в живых даже, и создается до сих пор. решается частная задача, и на ее основе движемся дальше, решаем следующую <nobr>и т. д.</nobr> и когда для решения некой частной задачи мне нужна какая то таблица, то я не знаю кому и для чего она понадобится через пять лет. но логику обработки данных знаю и прописываю ее в триггерах. и те кто будет использовать эту таблицу дальше о логике могут не париться, просто редактировать. если выйдут из условий триггер остановит их потуги.
>ну както все у вас запутано… не по феншую!!!
так мы ж не специализированная контора по разработке ПО. отдел айтишнегов выросший из еще советского ВЦ эт вы можете одно приложение разработать и потом жировать годами, а мы решаем насущные проблемы производства по мере их возникновения. планируем конечно, что в течении года двух будем окучивать, но бывает, что и внеплановые задачки возникают. жаль конечно, что сейчас кой что из наработанного загоняют в 1С и довольно коряво, но тут мы бессильны
> > Йащур (Йащур) писал (а) в ответ на сообщение:
>> кстати, ХП реально скорость обработки повышают, в чем смысл от них отказываться?
>Каким макаром они скорость повышают? Ты про кеширование планов? >
кэширование, компиляция. однозначно быстрее чем из клиента запросами.
> Йащур (Йащур) писал (а) в ответ на сообщение:
>> по сути да. клиенты скрипты на сиквеле, простые текстовые файлы и оракловский компонент их пережевывающий.
> > Это какой же версии у вас Оракл, что даже ODBC не понимает? > А API компонента, че нет? Как-то приложение через него работает, кто-то же его писал…
а хз не помню. в понедельнег если не забуду отпишусь какая версия. на заводе он с 94-го так что начала 90-х видимо. приложение это скрипты на сиквеле хех хоть в блокноте пиши. и некий екзешник из комплекта оракла которому этот скрипт подсовывается в батнике. и никаких API. проблема может еще в том что он не под виндами, а под полуосью крутится.
Врут наверное… Стандарт 10%… Особо охреневшие 12% берут!
