powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Весомый плюс Юкон над ORACLE
200 сообщений из 200, показаны все 8 страниц
Весомый плюс Юкон над ORACLE
    #32813079
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В Юкон будет реализована возможность программировать триггеры, ХП, UDF с помощью любого .NET
совместимого языка (такого как Visual Basic® .NET и C#).
Мне кажется это весомым плюсом в сравнении с ORACLE, где есть поддержка только Java.

Вот даже выдержка из прооракловского документа :

.NET in MSSQL vs. Java in Oracle
It is looks like MSSQL 2005 has a serious advantage over Oracle. Java inside Oracle database can be called only indirectly meaning that it should be wrapped by PL/SQL or by using either CORBA or EJB interfaces while .NET in MSSQL can be called absolutely transparently as Transact-SQL. In addition, uploading and maintaining of Java objects in Oracle is the same as maintaining a complete java application server. On the other hand, MSSQL provides a simple interface to develop, debug and use .NET triggers, stored procedures and packages in the MSSQL 2005.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813098
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет, StalkerS!
Ты пишешь:

StalkerS S> В Юкон будет реализована возможность программировать триггеры, ХП, UDF с помощью любого .NET
S> совместимого языка (такого как Visual BasicR .NET и C#).
S> Мне кажется это весомым плюсом в сравнении с ORACLE, где есть поддержка только Java.
Visual Basic форева!!!!
Ураааа!!!
Заменим Басиком SQL !!!!
Ураааа 2 раза!!!

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813125
Sarin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Имхо если язык (SQL) создан специально для какой либо узкой задачи то, вероятно, он превосходит другие языки (применительно к решению этих задачь) для решения более широких задачь.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813147
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В Оракле PL/SQL достаточно функциональный и удобный для реализации логики на стороне сервера. Поэтому поддержку Java можно считать приятным дополнением и маркетинговым ходом. В MSSQL вместо того, чтобы доработать TSQL до приемлимого уровня и избавиться от пережитков прошлого, MS как всегда "быстро" решила проблему, прикрутив туда .NET и заодно заставляя пользователей использовать C# или VB.NET (что в принципе делается постоянно - вспомнить тот же Access ADP).

IMHO мне не кажется это преимуществом новой версии MSSQL, я вообще против того, чтобы в СУБД пихали подряд новомодные маркетинговые фичи. Если СУБД используется совместно с Java или .NET, то обычно в 3-х звенках, а не хранимых процедурах БД. Например, в ASA наоборот в текущей 9-ой версии возможности хранения Java-обьектов и работы с ними в WatcomSQL ХП обьявили как Depricated, оставив только возможность использования в БД внешних ХП, написанных на Java. Мотивация была простая - эти фичи за годы существования так и не были востребованны пользователями ASA, а на фоне навороченного WatcomSQL и интегрированной в эту СУБД прекрасной поддержки XML и веб-сервисов (вплоть до организации через веб-сервисы вызовов ХП и запросов, с передачей запросов и наборов данных через XML) по опросам пользователей Java оказалась не только не нужна, но и просто мешалась iAnywhere под ногами для дальнейшего развития этой СУБД. Лично я с ними полностью согласен, думаю для СУБД главное надежность и скорость работы, а при вводе любой сторонней платформы эти параметры здорово снижаются (тем более когда это виртуальные машины со сборщиками мусора).
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813152
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerSВ Юкон будет реализована возможность программировать триггеры, ХП, UDF с помощью любого .NET
совместимого языка (такого как Visual Basic® .NET и C#).
Мне кажется это весомым плюсом в сравнении с ORACLE, где есть поддержка только Java.


Ну дак когда будет реализована, тогда и обсудим.
А то у меня тут идей - так вообще прорва! Ух, как размахнусь, К-А-А-К напишу!
Кстати, сколько глюков там запланировано?
M$ VisualStudio работать-то будет, или как в XP, после 3-го SP. MSVS попал в список несовместимых с XP продуктов?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813156
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> M$ VisualStudio работать-то будет, или как в XP, после 3-го SP. MSVS попал в список несовместимых с XP продуктов?или как в XP, после 3-го SP. MSVS попал в список несовместимых с XP продуктов?

У меня после установки 3-го SP все прекрасно продолжает работать, в том числе и M$ VisualStudio.... Может у меня с руками что-то не так?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813161
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2:www.fun4me.narod.ru

Опечатался, SP2
А вообще почитай тут:
http://www.compulenta.ru/2004/12/2/52343/
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813167
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.NET - это платформа на которую microsoft сделала ставку, они вбухивают в нее огромные деньги, так что
полная интеграция MSSQL и .NET открывает большие возможности.

Я, например, не вижу ничего плохого в том, что можно будет пользоваться огромной библиотекой классов,
и вообще всеми достоинствами полнофункциональных языков.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813170
Sarin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Плохо будет, если они на старый добрый SQL болт забъют.
Вопрос: какие функции, необходимые при работе с БД НЕ реализованны в анси 92?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813171
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Еще, наверное, интересно это прочитать:
http://www.compulenta.ru/2004/11/29/52207/
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813174
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
лет через 5 должна победить одна из моделей - или субд будет лишь хранилищем для апп-сервера или апп-сервер сольется в экстазе с субд. поэтому - что java что .Net это пока закидывание удочек.
java в оракле (которая в субд) не используют для написания бизнес логики, это то что иногда применяют когда это на pl/sql реализовать слишком сложно, и бывает, что очень выручает. T-SQL гораздо беднее, и подобная выручалочка просто необходимость.

Java и .Net врядли в ближаейшее время по производительности приблизятся к T-SQL/PLSQL поэтому имхо перспективней какойнибудь php/sql или perl в posgres. там и ооп и конструкции языка на 5 лет впереди ... жаль херово работает :)


ЗЫ. а IBM похоже засунет .Net в db2 раньше ...
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813224
StalkerSВ Юкон будет реализована возможность программировать триггеры, ХП, UDF с помощью любого .NET
совместимого языка (такого как Visual Basic® .NET и C#).
Мне кажется это весомым плюсом в сравнении с ORACLE, где есть поддержка только Java.

1) А как обеспечить переносимостью такого кода на UNIX?
2) Что с производительностью по сравнению с родным языком ХП?
2) Зачем вообще перегружать СУБД бизнес-логикой? Для этого серверы приложений придумали, да и еще J2EE и .NET.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813270
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Андрей Прохоров
1) А как обеспечить переносимостью такого кода на UNIX?
Вобщето MS SQL под UNIX делать пока не планируется. Но вот .Net там вполне может быть и тут с переносимостью проблем не возникнет - на то она и .Net чтоб ни от чего не зависеть.

2) Что с производительностью по сравнению с родным языком ХП?
Родной язык всё равно останется

2) Зачем вообще перегружать СУБД бизнес-логикой? Для этого серверы приложений придумали, да и еще J2EE и .NET.
А зачем иметь два сервера, когда можно обойтись одним?

А вообще трудно не согласиться с ASCRUSом - лучше бы они T-SQL-ю больше внимания обращали, плюс совсем невесомый получается
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813315
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а почему все так уверены, что в T-SQL нет усовершенствований? Во всяком случае, вот что у них в официальном документе написано

Transact-SQL Enhancements

Yukon provides more new language constructs and primitives for the T-SQL language than can be enumerated here. You can find them all in SQL Server Yukon Books Online. The enhancements to the T-SQL language reflect greater conformity to the ANSI-99 SQL specification, and were prompted by customer requests. Many of the improvements in T-SQL are focused on greater expressiveness in queries. There are several new query types that allow for common scenarios to be covered in T-SQL code. For example, a recursive query provides the ability to generate a bill of materials or a hierarchical resultset.

T-SQL in Yukon provides new PIVOT and UNPIVOT operators. These operators perform a manipulation on an input table-valued expression and produce an output table as a resultset. The PIVOT operator rotates rows into columns, optionally performing aggregations or other mathematical calculations along the way. It widens the input table expression based on a given pivot column and generates an output table with a column for each unique value in the pivot column. The UNPIVOT operator performs an operation opposite to the one PIVOT performs; it rotates columns into rows. The UNPIVOT operator narrows the input table expression based on a pivot column.

Yukon introduces a new and simple but very powerful exception handling mechanism in the form of a TRY/CATCH T-SQL construct. Transaction abort errors that used to cause a batch to terminate can now be caught and handled. Additionally, there are new language constructs for security, replication, Notification Services, XML, and all of the features that the .NET Framework provides. The .NET Framework implementation on the server is an important evolution in the SQL Server product cycle.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813364
SergSuper1) Вобщето MS SQL под UNIX делать пока не планируется. Но вот .Net там вполне может быть и тут с переносимостью проблем не возникнет - на то она и .Net чтоб ни от чего не зависеть.

Для Oracle переносимость ХП и триггеров принципиальна.
SergSuper2) Родной язык всё равно останется
Это понятно, вопрос в производительности кода на .NET по сравнению с Transact SQL.
SergSuper2) А зачем иметь два сервера, когда можно обойтись одним?
Тогда зачем вообще .NET нужен?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813433
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А теперь вернемся к самому топику:
- Весомый плюс Юкон над ORACLE -

более правильно: Весомый плюс ORACLE над Юкон - это то, что Oracle - уже есть, а Юкона - еще нет. Дык что с чем сравнивать-то?
Как можно оценивать то, что есть, с тем чего нет?
NULL можно сравнить только c NULL.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32813575
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
null нельзя сравнивать даже с null
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32814431
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerSМне кажется это весомым плюсом в сравнении с ORACLE, где есть поддержка только Java.
Поскольку это утверждение - неверно само по себе, сравнение, мягко говоря, малоосмысленно. Вернее, сравнение в пользу Oracle, в котором можно писать и не на .NET-языках.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32814494
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
странно что по поводу .Net такая эйфория. IBM DB2 уже реализовала эту возможность в версии 8.2
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32814495
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerSВ Юкон будет реализована возможность программировать триггеры, ХП, UDF с помощью любого .NET
совместимого языка (такого как Visual Basic® .NET и C#).


Ключевые для понимания слова выделены жирным. Когда они перейдут в настоящее время - будем разговаривать.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32815255
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Когда они перейдут в настоящее время - будем разговаривать.

Тогда может будет уже поздно. Нужно сейчас уже что-то предпринмать.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32815269
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет, vadiminfo!
Ты пишешь:

vadiminfo MasterZivКогда они перейдут в настоящее время - будем разговаривать.
Тогда может будет уже поздно.
Нужно сейчас уже что-то предпринмать.
Предлагаю предпринять поход в кабак!
Пиво - вот достойный ответ проискам сил мирового империализЪма!

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32815292
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мимопроходящий
vadiminfo MasterZivКогда они перейдут в настоящее время - будем разговаривать.
Тогда может будет уже поздно.
Нужно сейчас уже что-то предпринмать.
Предлагаю предпринять поход в кабак!
Пиво - вот достойный ответ проискам сил мирового империализЪма!


Поддерживаю!!!
То, что осталось на плаву, т.е. не утонуло в Пиве - продукт стоящий!
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32815297
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не доконца мысль излил...
Ударим Пивом по M$-рожью и разгильдяйству !!!
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32815482
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 gardenman

>странно что по поводу .Net такая эйфория. IBM DB2 уже реализовала эту возможность в версии 8.2

Так вот оно же и есть самое главное: не важно что, где и как реализовано, важно чтоб эйфория была. Бабки-то платят те, кто в эту эйфорию втянут прямо или косвенно. А они, зеленые, и есть конечная и единственная цель.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819023
Фотография segun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Давайте разберемся по пунктам
1. gardenmanстранно что по поводу .Net такая эйфория. IBM DB2 уже реализовала эту возможность в версии 8.2что значит уже реализоваЛА?
В статье Сможет ли Stinger затмить Yukon? есть фраза: "Во всех статьях рассказывалось о предстоящем выпуске DB2 UDB 8.2 (условное название Stinger) осенью 2005 г. ". Или я что-то пропустил?

2. По поводу интеграции .Net Framework и SQL2k5 есть хорошая презентация ( Программирование для SQL Server 2005 с использованием .NET Framework 2.0 ), раскрывающая смысл такой интеграции, возможности, а также рекомендации на тему когда использовать T-SQL а когда .Net языки. От себя могу добавить (если кто поленится скачать), что для работы с данными (select/insert/update/delete) конечно ничего в MS SQL Server не будет быстрее T-SQL. Однако, если в процедуре нам нужен цикл, например, или другая подобная логика, отходящая от перечисленных выше команд, то такая процедура прямой кандидат для реализации на .Net. И она будет работать намного быстрее, даже на SQL2k5 beta2. Несмотря на то, что .Net будет работать с СУБД в одном процессе, как это не парадоксально для некоторых звучит, это не снизит производительность СУБД. Потом убедитесь сами. К тому же эту функциональность можно и не включать (по умолчанию Microsoft .NET Framework выключен).

3. По поводу "забытости" компанией T-SQL. На этом же сайте, благодаря Александру Гладченко, есть замечательная подборка материалов по SQL2k5 . В частности, там есть большая статья T-SQL Enhancements in SQL Server 2005 .
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819130
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
segunДавайте разберемся по пунктам
1. gardenmanстранно что по поводу .Net такая эйфория. IBM DB2 уже реализовала эту возможность в версии 8.2что значит уже реализоваЛА?
В статье Сможет ли Stinger затмить Yukon? есть фраза: "Во всех статьях рассказывалось о предстоящем выпуске DB2 UDB 8.2 (условное название Stinger) осенью 2005 г. ". Или я что-то пропустил?


DB2 v8.2 находится в продаже с сентября этого года. Если есть желание, можете взять триальную версию с сайта ИБМ
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819141
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Наверное это опечатка...
Кстати Oracle после выхода Stinger сделал анонс что тоже реализует такую функциональность правда когда не сказал...
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819143
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а MS триггера before так и не собираются делать?..
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819161
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819337
Фотография segun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanа MS триггера before так и не собираются делать?.. ИМХО, необходимость в BEFORE-триггере вполне перекрывается INSTEAD-триггерами. По крайней мере, я не смог придумать ситуацию, в которой BEFORE-триггер оказался бы существенно более полезным, нежели INSTEAD. Пусть меня поправят, если я не прав.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819352
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
странно, в других базах ORACLE,DB2 нашлось место и тем и другим...
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819357
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а триггеры на уровне строки тоже не нужны?... печально...
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819362
Фотография segun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
здорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819370
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
segunздорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before
Хм. Я затруднюсь придумать ситуацию, в которой нельзя обойтись вообще без триггеров. Но это не повод их не делать.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819427
Фотография segun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanстранно, в других базах ORACLE,DB2 нашлось место и тем и другим...я нашел пример, но врядли он вам понравится. это облегчение миграции с СУБД, в которых он реализован. На самом деле я не противник дополнительной функциональности, больше фич хороших и разных! Но так как MS постоянно проводит различные исследования на предмет как именно используются ее продукты в компаниях, какие у заказчиков есть пожелания к следующим версиям продуктов, их функциональности, простоты использования и т.д., и, с учетом этого, до сих пор нет триггеров before - это означает лишь одно. Пока есть более приоритетные вещи, чем эта разновидность триггеров. Значит они не так нужны при разработке решений на SQL Server, либо хорошо заменяются триггерами instead.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819490
Фотография Рыжий Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторНо так как MS постоянно проводит различные исследования на предмет как именно используются ее продукты в компаниях, какие у заказчиков есть пожелания к следующим версиям продуктов, их функциональности, простоты использования и т.д....

И вы думаете, что им важны ваши пожелания... :)

...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819528
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
segunздорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before

Ну например, вместо удаления записи, она переносится в архив.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819534
Фотография segun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Рыжий Кот
И вы думаете, что им важны ваши пожелания... :)

да. очень. и я не думаю, я знаю. или думаю что знаю. :)
не хочу никого лечить, но, на мой взгляд, на сегодняшний день это одна из самых открытых компаний-разработчиков ПО.
Кстати, если кто не знает, есть интересный сайт о том как создаются продукты в MS
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819541
Фотография segun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nik_x segunздорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера beforeНу например, вместо удаления записи, она переносится в архив.как переносится, физически? то есть в другую таблицу или секцию, если мы говорим о секционированной таблице?
Или удаление подразумевает просто обновление статуса записи?
Напишите немного подробнее пожалуйста.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32819722
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nik_x segunздорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before
Ну например, вместо удаления записи, она переносится в архив.
Для этого случая и after пойдёт. А если имелось ввиду что запись на самом деле не удаляется, а только ставится какой-то флаг - то тут как раз instead.
Чтобы из instead сделать before надо только одну строчку дописать, неужели это может быть так принципмально?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820046
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuper nik_x segunздорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before
Ну например, вместо удаления записи, она переносится в архив.
Для этого случая и after пойдёт. А если имелось ввиду что запись на самом деле не удаляется, а только ставится какой-то флаг - то тут как раз instead.
Чтобы из instead сделать before надо только одну строчку дописать, неужели это может быть так принципмально?

Уважаемый SegrSuper. У вас есть хорошая возможность меня убедить в том, что триггеры INSTEAD действительно могут заменить триггеры BEFORE.

Задача: имеется 2 таблицы
1) Проводки (id проводки,счет, сумма, дата)
2) Журнал_ движения (счет, дата, сумма оборотов за день)

реализовать:
1) При добавлении записи в журнал движения по счету сумма оборотов за день формируется как select sum(сумма) from Проводки where Проводки.счет=
Журнал_движения.счет и Проводки.дата=Журнал_движения.дата
2) при добавлении в таблицу Проводок записи, если уже сформирован журнал движения, то возвращается ошибка.
3) если существует журнал движения за конкретную дату, то нельзя удалить запись в таблице проводок за эту дату, т.е. сначала должен быть удален журнал проводок.
Реализовать всю схему без использования ХП,исключительно на триггерах
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820112
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 gardenman
А зачем тут before триггеры? Во всяком случае у меня несколько более сложная схема проводок (наверняка и Вы тут упростили свою задачу) и всё на триггерах after.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820160
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, я упростил до невозможности.
первый триггер Before должен проинициализировать сумму в таблице движения до вставки записи.
второй триггер before должен возвратить ошибку до вставки в таблицу проводок
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820175
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
и еще вопросик, сколько тригеров INSTEAD OF INSERT одновременно может висеть на одной таблице?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820342
e60
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИМХО практика доказала, что все в одном (Сервак приложений и СУБД) рассчитано на универсальность, что означает потерю производительности.
Моя мнение такое должна быть СУБД с SQL и отдельный Application Server. Ведь это распределнная логика, которая быстрее по своей сути.
Вот пример:
Есть СУБД и несколько клиентских программ. Скажем так одни клиентские приложения используют простые запросы для получения текущей информации, а другие клиенты используют сложные запросы + доп возможности .NET и т.п.
При распределении простые приложения будут общаться напрямую с СУБД, а сложные через сервер приложений.
Если же будет все в одном, то и те и другие будут задействовать и СУБД и сервер приложений
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820361
Фотография segun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2gardenman: 99.99% всех задач, реализованных на DB2, Oracle или другой RDBMS можно сделать на SQLServer без особых проблем, думаю вы с этим не будете сильно спорить. Обратное, несомненно, тоже верно. (0.01% я не указал на всякий случай, не более того). Неужели вы думаете, что такая простая задача не реализуема с помощью SQLServer? Методы решения могут отличаться, но заказчик отличий не увидит.
Данная задача решается с помощью хранимых процедур или триггеров instead of. Неясно, по какой причине вы сразу отклонили использование процедур, ну да ладно. Главное - что она решается. И без каких-либо потерь в производительности. Давайте все-таки не будем проверять функциональную пригодность SQLServer. Я же вас не спрашиваю, почему уязвимостей в безопасности Oracle больше чем в SQLServer .

По поводу кол-ва триггеров instead of insert на одной таблице - ответ 1. И тем не менее я не думаю что это повод для баталий.

Мы живем в интересное время когда конкуренция между основными лидерами RDBMS + mySQL заставляет компаний-разработчиков дополнять свои продукты все новыми и новыми возможностями. И это касается не только SQLServer. Например Oracle говорит о том что до выхода 10g все было классно, за исключением, может быть, управляемости. И теперь все стало еще лучше. Значит всем, а не только SQLServer есть куда стремиться? На мой взгляд, это нормальное развитие ситуации.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820410
e60
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
segun2gardenman: 99.99% всех задач, реализованных на DB2, Oracle или другой RDBMS можно сделать на SQLServer без особых проблем, думаю вы с этим не будете сильно спорить. Обратное, несомненно, тоже верно. (0.01% я не указал на всякий случай, не более того). Неужели вы думаете, что такая простая задача не реализуема с помощью SQLServer? Методы решения могут отличаться, но заказчик отличий не увидит.
Данная задача решается с помощью хранимых процедур или триггеров instead of. Неясно, по какой причине вы сразу отклонили использование процедур, ну да ладно. Главное - что она решается. И без каких-либо потерь в производительности. Давайте все-таки не будем проверять функциональную пригодность SQLServer. Я же вас не спрашиваю, почему уязвимостей в безопасности Oracle больше чем в SQLServer .

По поводу кол-ва триггеров instead of insert на одной таблице - ответ 1. И тем не менее я не думаю что это повод для баталий.

Мы живем в интересное время когда конкуренция между основными лидерами RDBMS + mySQL заставляет компаний-разработчиков дополнять свои продукты все новыми и новыми возможностями. И это касается не только SQLServer. Например Oracle говорит о том что до выхода 10g все было классно, за исключением, может быть, управляемости. И теперь все стало еще лучше. Значит всем, а не только SQLServer есть куда стремиться? На мой взгляд, это нормальное развитие ситуации.
Ну по-поводу уязвимости это Вы загнули. SQLServer - на MS Windows, котороая по сути уязвимей, чем *nix системы. А если уязвима ОС, то вы на нее хоть черта ставьте - не поможет
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820438
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
мда .. меняем mssql на mysql а оракл на mssql и понимаем какую чушь пороли :)

--------
99.99% всех задач, реализованных на mssql или другой RDBMS можно сделать на mysql без особых проблем, думаю вы с этим не будете сильно спорить. Обратное, несомненно, тоже верно. (0.01% я не указал на всякий случай, не более того). Неужели вы думаете, что такая простая задача не реализуема с помощью mysql ? Методы решения могут отличаться, но заказчик отличий не увидит.
Данная задача решается с помощью выноса логики на апп-сервер.Неясно, по какой причине вы сразу отклонили использование апп-сервера, ну да ладно. Главное - что она решается. И без каких-либо потерь в производительности. Давайте все-таки не будем проверять функциональную пригодность mysql. Я же вас не спрашиваю, почему уязвимостей в безопасности mssql больше чем в mysql.
--------

ЗЫ. mssql это пока единственная субд добившееся действительно впечатляющих результатов в области секурити - это единственая субд с вирусами на пару дней вывела из строя целый регион. такое еще никому не удавалось.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820439
Фотография segun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Приведите, пожалуйста, ссылки на независимые компании в которых были проведены эти исследования. Например, за 2003-2004 годы.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820465
Фотография segun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Yo!:
глупо отрицать успехи конкурентов, и в частности mySQL. Все-таки почему так тянет пособачиться? Экскрементов на вентилятор любой СУБД можно бросить предостаточно.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820486
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
мне просто хотелось показать как глупо выглядело вашу утверждение о 99% :) думаю мне это удалось ...
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820500
Фотография Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Реально разработчику БД приходится знать кроме классического SQL, фирменные навороты в виде PL/SQL или T-SQL, не считая языка разработки "морды".
Логично перевести логику, обработку ошибок, строковые и другие ф-ции на язык разработки. Старая идея в новом воплощении от MS.
У ORACLE оказалась не очень востребована интеграция с java.
Посмотрим, что будет у MS. Пока многообещающе звучит.
Опять же, MS обычно начинает позже других, гармотно учитывает чужие ошибки и потом зачастую выигрывает ;)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820530
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 sergun
Вы правы, систему можно реализовать несколькими сособами. Про эффективность говорить не будем.
Почему я сразу отклонил использование ХП? я постараюсь ответить. Все это конечно ИМХО.
Когда я создаю модель, то стораюсь сделать ее как можно более надежной дуракозащищенной , не только от пользователей, но и от своих собственных ошибок и ошибок других программистов. Чтоб другой программист, каким бы ломом или кувалдой не бил по моей модели, т.е. какие бы кривые ХП не писал, данные всегда бы оставались согласованными. Совокупность триггеров BEFORE/AFTER/INSTEAD, UNIQUE INDEX, PRIMARY&FOREIGN KEY, CHECK CONSTRAINT - как раз и позволяют это сделать. Что касается ХП...)) То эту задачу на них складывать не люблю. Я считаю ХП - прикладным уровнем и не дело ХП следить за согласованностью данных. Во всех системах этих ХП столько, что в каждой из них упомнить что и как сосгласовывается - очень трудно. Перенося проверку согласованности на ХП (а проверять согласованность так или иначе все равно когда-нить да придется) вы загромождаете код ХП. использование триггеров позволяет делать системы более модульными, понятными.
Можете со мной не соглашаться. Я просто люблю экономить свое время, и не переписывать одно и то же по нескольку раз. Конечно это все субъективно.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820545
Фотография segun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2Yo!: молодой человек, вам удалось только показать свое воспитание и нетерпимость к инакомыслию.

2Leonid: ну да, звучит многообещающе, тем более, как я упоминал выше, если .Net в БД не будет нужен - его можно будет и не включать. То же самое касается и некоторых других частей продукта.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820581
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 gardenman
первый триггер Before должен проинициализировать сумму в таблице движения до вставки записи.
из условий это никак не вытекает. Какая разница сначала просчитать или потом? Проводки то за это время не меняются.

второй триггер before должен возвратить ошибку до вставки в таблицу проводок
во-первых если произошла ошибка и делается роллбэк - то не важно была вставка или нет, во вторых это можно сделать констрейтами
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820593
Фотография Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Еще хорошо, что ".NET логика" в Yukon будет по умолчанию компилироваться в nativ код и будет выполняться явно быстрее
чем T-SQL логика.
Народ уже проверял на MSSQL Server 2005 Express Beta2 - реально быстро.
У ORACLE PL/SQL тоже можно откомпилировать в nativ код, но несколько геморойнее. А вот java у него явно тормознутая.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820651
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
>молодой человек, вам удалось только показать свое воспитание и нетерпимость к инакомыслию.

да вот такие мы иные :) (sybase, db2 и oracle ) со своими ненужными тригерами, и иным версионым механизмом (snapshot) и джавой (.Net), iFs (WinFs) и другими не нужными вещами еще незапланированых в Юконе ;)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820655
Фотография segun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2gardenman: вы будете удивлены, но я согласен с вашим постингом от 12:47 :)
тем не менее, можно на SQLServer сделать это только на триггерах, можно. Если не все (оговариваюсь опять же на всякий случай), то особо важную часть. Триггеры + udf-функции. Я с SQLServer работаю больше 5 лет и делал проекты в разных областях: банки, аналитические приложения, интернет/интранет сайты. Поверьте, опыт большой. Но я нигде не перекладывал все логику работы с данными только на триггеры. Возможно это именно из-за особенностей SQLServer. Возможно на Oracle я бы делал все на триггерах :). Однако, есть задачи в которых защита от дурака чувствительно влияет на производительность, поэтому, не всегда она имеет смысл в полном объеме на уровне схемы. Все это, разумеется, ИМХО.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820656
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот не понимаю я, какой такой там код в ХП нужен, что так скорость выполнения его критична. У меня в ХП в основном DML команды, все остальное только их связывает. Если что то и реально может тормозить, так это запросы, поэтому надо думать разработчики СУБД не просто так нянчяться с оптимизатороми запросов и постоянно их совершенствуют. Ну а если уж реально какой то код расчета чего то не имеющего прямого отношения к БД хочется делать, так Си никто не отменял, пишите внешние функции, подключайте, наслаждайтесь скоростью. Или выносите на 3-е звено, если бизнес-логика сложная, тут до фени - C#, Java, Delphi, PowerBuilder, и т.д. Не надо СУБД превращать в помойку, а то так докатимся, что через n-лет выйдет DOOM 4 на базе MSSQL. Поэтому я и считаю .NET в MSSQL просто маркетинговой фишкой - нормальные разработчики БД не рискнут на сервере поднимать виртуальную .NET машину, отдавая в обмен ресурсы, скорость и надежность и вполне оправданно будут бурчать, что лучше бы TSQL расширили, избавились от многих "исторически сложилось" и разного геммора, который конечно же можно обойти, но затратив дополнительные усилия, а то и вообще сначала дойдя до белого каления.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820727
Фотография Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUSУ меня в ХП в основном DML команды, все остальное только их связывает. Если что то и реально может тормозить, так это запросы, поэтому надо думать разработчики СУБД не просто так нянчяться с оптимизатороми запросов и постоянно их совершенствуют.
Ну с этим, слава богу, у MS вроде все впорядке.

ASCRUSНу а если уж реально какой то код расчета чего то не имеющего прямого отношения к БД хочется делать, так Си никто не отменял, пишите внешние функции, подключайте, наслаждайтесь скоростью. Или выносите на 3-е звено, если бизнес-логика сложная, тут до фени - C#, Java, Delphi, PowerBuilder, и т.д
Да все можно и сейчас. Кто спорит-то? Хочется удобнее и проще.

ASCRUSНе надо СУБД превращать в помойку, а то так докатимся, что через n-лет выйдет DOOM 4 на базе MSSQL.
Так это ж круто! Можно будет: SELECT секретки FROM уровень WHERE бонус >= "до хрена"

Если серьезно, то почему же в помойку. Никто не отменит SQL и грамотное построение запросов, но то "что их связывает" пока оставляет желать лучшего и к то му же очень специфично от сервера к серверу.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820790
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeonidЕсли серьезно, то почему же в помойку. Никто не отменит SQL и грамотное построение запросов, но то "что их связывает" пока оставляет желать лучшего и к то му же очень специфично от сервера к серверу.
А Вы никогда не задавались вопросом - почему в других СУБД (Oracle, IBM DB2, Sybase ASA, Sybase ASE) уже как сто лет существует поддержка Java (внешние ХП, хранение обьектов Java в таблицах, возможность их использования в ХП и т.д.) - и это никем массово не было востребовано ? И вроде везде толково реализовано и народ Java вроде как знает. Почему у меня сейчас на сервере стоит СУБД ASA, в которой берешь Java и делаешь что хочешь в БД, а я ни разу даже не попытался Java там запустить ? Надо думать на все эти вопросы будет 2 ответа:
1. "Повода не возникало"(прямо как в анекдоте про мальчика, который молчал)
2. Затраты на реализацию и сопровождение бизнес-логики работы с данными родным диалектом языка ХП гораздо ниже, чем на ООП языке
Ну так неужели включение в MSSQL поддержки .NET резко ускорит разработки на нем, выведет на новый уровень, даст большие возможности по манипуляции и обработке данных ? Пока я лично вижу одно применение этой фичи - на ней будет удобно делать то, что "случайно" забыли реализовать в TSQL и обходить различные баги СУБД.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820808
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 ASCRUS
Садись, ПЬЯТЬ! )
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820839
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
2ASCRUS

вы не правы. рассказывать где я видел не буду, смысла мало. более серьозно выглядет то что оракл часть своих модулей для OEBS разрабатывал используя и джаву (ту что в субд). в Collbaoration Suite & Oracle workflow тоже для большинства фич продублированы pl/sql апи и java.
сильно сомневаюсь что они это делали просто для маркетинговой галочки. все отлично понимают насколько убог pl/sql и что это должно как-то изменится, просто никто незнает как. примерно как с гридами, все понимают что полезности пока от них мало, но в то же время уверены что за ними будущее.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820919
Фотография Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUS2. Затраты на реализацию и сопровождение бизнес-логики работы с данными родным диалектом языка ХП гораздо ниже, чем на ООП языке
Вот этот "тонкий" момент MS и хочет обыграть, и есть вероятность, что это ей удасться лучше конкурентов, потому как все свое и системы разработки/отладки замечательно друг в друга интегрируются.

ASCRUSПока я лично вижу одно применение этой фичи - на ней будет удобно делать то, что "случайно" забыли реализовать в TSQL и обходить различные баги СУБД.Ну, не знаю... А я вот хотел бы видеть в этом то, что при написании той же ХП, я бы логику и переменные описывал бы на привычном "мне" подмножестве .NET диалектов: С#, Delphi.NET, а не вспоминал бы каждый раз как это я там последний раз извращался на T-SQL.
А SQL Server занимался бы тем, чем должен - выполнением и оптимизацией собственно SQL и возвращением или модификацией набора данных.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32820986
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Yo!

Вы ОЧЕВИДНО крупный специалист по ЭТОМУ вопросу ;)
Было-бы ОЧЕНЬ интересно послушать НАСКОЛЬКО убог PL/SQL ?
И самое главное ЧЕМ ???

Зарание СПАСИБО.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821196
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)2 Yo!

Вы ОЧЕВИДНО крупный специалист по ЭТОМУ вопросу ;)
Было-бы ОЧЕНЬ интересно послушать НАСКОЛЬКО убог PL/SQL ?
И самое главное ЧЕМ ???

Зарание СПАСИБО.

Плохой танцор - хороший папа!
(надеюсь оригинал все знают)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821247
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
авторВы ОЧЕВИДНО крупный специалист по ЭТОМУ вопросу ;)
Было-бы ОЧЕНЬ интересно послушать НАСКОЛЬКО убог PL/SQL ?
И самое главное ЧЕМ ???


всем, нет ассоциативных масивов, те зачатки в виде колекций вызывают только задражение, т.к. инструменто для работы с ними нет.
как язык pl/sql не развивается уже лет 7. нука просветите меня что было добавлено в язык за последнии 7 лет ? ничего стоящего - даже perl и php гораздо прродвинутей.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821287
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeonidА я вот хотел бы видеть в этом то, что при написании той же ХП, я бы логику и переменные описывал бы на привычном "мне" подмножестве .NET диалектов: С#, Delphi.NET, а не вспоминал бы каждый раз как это я там последний раз извращался на T-SQL.
А вот это и есть ключевая фраза - психологический момент восприятия принципов работы с технологиями. Вместо того, чтобы осознать бесполезность багажа известной технологии в какой то другой, частенько предпринимаются попытки "подогнать" средство под свое привычное мировозрение, далее затратив кучу усилий и полностью осознав мудрое назначение поговорки "Чем дальше в лес, тем больше дров", остается или признать себя дураком и все таки начать думать по другому или же обвинить во всех смертных грехах неподдающуюся технологию. Из наиболее таких ярких примером мне встречались связки перехода специалистов FoxPro/Delphi->логика на SQL, Access/VB->Delphi, Delphi->Java, Delphi->PowerBuilder, можно было смеяться и плакать одновременно, одновременно удивляясь упорству. Тут как раз в тему вспоминается анекдот о том, как сотрудникам вручили квадраты с заданием вложить их в маленькие шарики и по результатам тестов было определено, что половина из сотрудников глупые, а половина очень сильные (за дословность не ручаюсь) :)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821336
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo! авторВы ОЧЕВИДНО крупный специалист по ЭТОМУ вопросу ;)
Было-бы ОЧЕНЬ интересно послушать НАСКОЛЬКО убог PL/SQL ?
И самое главное ЧЕМ ???


всем, нет ассоциативных масивов, те зачатки в виде колекций вызывают только задражение, т.к. инструменто для работы с ними нет.
как язык pl/sql не развивается уже лет 7. нука просветите меня что было добавлено в язык за последнии 7 лет ? ничего стоящего - даже perl и php гораздо прродвинутей.

Ооо, Вы действительно крупный специалист :) ассоциативные массивы ЕСТЬ (и даже по не числовому индексу) и я ими как и коллекциями, автономными транзакциями, временными таблицами, обработкой исключений, пакетами, партиционированием, всевозможными видами триггеров на все что шевелится и т.д. и т.п. АКТИВНО пользуюс в работе. По поводу новых возможностей почитайте списки фич, публикуемые с каждым новым релизом. Уверяю Вас, их добавлено немало. Очевидно, про то, что PL/SQL работает гораздо более оптимально (например в части снижения количества мягких разборов) ВАМ говорить БЕСПОЛЕЗНО, бисер дорог
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821361
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Имелось в виду PL/SQL работает корректнее Явы. По крайней мере при одинаковых затраченных усилиях на написание и отладку кода.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821368
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
2Gluck

ну и что сними можно сделать ? применить 2 функции ? то что кроме pl/sql данные нечем ворочить это не оправдание 7 лет не развивать язык.

гребаный пхп и тот на порядок навороченей, что из этого есть в pl/sql ?

Table of Contents
array_change_key_case -- Returns an array with all string keys lowercased or uppercased
array_chunk -- Split an array into chunks
array_combine -- Creates an array by using one array for keys and another for its values
array_count_values -- Counts all the values of an array
array_diff_assoc -- Computes the difference of arrays with additional index check
array_diff_key -- Computes the difference of arrays using keys for comparison
array_diff_uassoc -- Computes the difference of arrays with additional index check which is performed by a user supplied callback function
array_diff_ukey -- Computes the difference of arrays using a callback function on the keys for comparison
array_diff -- Computes the difference of arrays
array_fill -- Fill an array with values
array_filter -- Filters elements of an array using a callback function
array_flip -- Exchanges all keys with their associated values in an array
array_intersect_assoc -- Computes the intersection of arrays with additional index check
array_intersect_key -- Computes the intersection of arrays using keys for comparison
array_intersect_uassoc -- Computes the intersection of arrays with additional index check, compares indexes by a callback function
array_intersect_ukey -- Computes the intersection of arrays using a callback function on the keys for comparison
array_intersect -- Computes the intersection of arrays
array_key_exists -- Checks if the given key or index exists in the array
array_keys -- Return all the keys of an array
array_map -- Applies the callback to the elements of the given arrays
array_merge_recursive -- Merge two or more arrays recursively
array_merge -- Merge one or more arrays
array_multisort -- Sort multiple or multi-dimensional arrays
array_pad -- Pad array to the specified length with a value
array_pop -- Pop the element off the end of array
array_push -- Push one or more elements onto the end of array
array_rand -- Pick one or more random entries out of an array
array_reduce -- Iteratively reduce the array to a single value using a callback function
array_reverse -- Return an array with elements in reverse order
array_search -- Searches the array for a given value and returns the corresponding key if successful
array_shift -- Shift an element off the beginning of array
array_slice -- Extract a slice of the array
array_splice -- Remove a portion of the array and replace it with something else
array_sum -- Calculate the sum of values in an array
array_udiff_assoc -- Computes the difference of arrays with additional index check, compares data by a callback function
array_udiff_uassoc -- Computes the difference of arrays with additional index check, compares data and indexes by a callback function
array_udiff -- Computes the difference of arrays by using a callback function for data comparison
array_uintersect_assoc -- Computes the intersection of arrays with additional index check, compares data by a callback function
array_uintersect_uassoc -- Computes the intersection of arrays with additional index check, compares data and indexes by a callback functions
array_uintersect -- Computes the intersection of arrays, compares data by a callback function
array_unique -- Removes duplicate values from an array
array_unshift -- Prepend one or more elements to the beginning of an array
array_values -- Return all the values of an array
array_walk_recursive -- Apply a user function recursively to every member of an array
array_walk -- Apply a user function to every member of an array
array -- Create an array
arsort -- Sort an array in reverse order and maintain index association
asort -- Sort an array and maintain index association
compact -- Create array containing variables and their values
count -- Count elements in an array, or properties in an object
current -- Return the current element in an array
each -- Return the current key and value pair from an array and advance the array cursor
end -- Set the internal pointer of an array to its last element
extract -- Import variables into the current symbol table from an array
in_array -- Checks if a value exists in an array
key -- Fetch a key from an associative array
krsort -- Sort an array by key in reverse order
ksort -- Sort an array by key
list -- Assign variables as if they were an array
natcasesort -- Sort an array using a case insensitive "natural order" algorithm
natsort -- Sort an array using a "natural order" algorithm
next -- Advance the internal array pointer of an array
pos -- Alias of current()
prev -- Rewind the internal array pointer
range -- Create an array containing a range of elements
reset -- Set the internal pointer of an array to its first element
rsort -- Sort an array in reverse order
shuffle -- Shuffle an array
sizeof -- Alias of count()
sort -- Sort an array
uasort -- Sort an array with a user-defined comparison function and maintain index association
uksort -- Sort an array by keys using a user-defined comparison function
usort -- Sort an array by values using a user-defined comparison function
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821373
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo! авторВы ОЧЕВИДНО крупный специалист по ЭТОМУ вопросу ;)
Было-бы ОЧЕНЬ интересно послушать НАСКОЛЬКО убог PL/SQL ?
И самое главное ЧЕМ ???


всем, нет ассоциативных масивов, те зачатки в виде колекций вызывают только задражение, т.к. инструменто для работы с ними нет.
как язык pl/sql не развивается уже лет 7. нука просветите меня что было добавлено в язык за последнии 7 лет ? ничего стоящего - даже perl и php гораздо прродвинутей.

Дык и C++, однако, последние 6 лет то-же не развивается.
На помойку его? Тогда посоветый это MicroSoft, а то они бедняги, до сих пор на нем пишут...

Ну а насчет PL/SQL, коль не дошло, то:
ПЛОХОМУ ТАНЦОРУ - ЯЙЦА МЕШАЮТ !
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821422
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По поводу множества ценнейших операций с массивами php:как насчет того, что часть из этого должна быть сделана на sql?Уж явно sort_array проще заменить на order by или вы любить делать хитрые fetch основываясь на упорядоченности исходного массива или php имеет оптимизатор с индексами?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821435
Фотография Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUSА вот это и есть ключевая фраза - психологический момент восприятия принципов работы с технологиями...
Странно Вы рассуждаете. Несовсем понял про переходы, ну да ладно.

Возвращаясь к теме, я вот не пойму, что вы держитесь за T-SQL как надстройку? Чем лучше этот "клей" между SQL операторами, чем полнофункциональный язык, не пойму?
Я не со стороны рассуждаю. Мне очень часто приходится писать на T-SQL большие процедуры и я, поверте, знаю что говорю.
Нет стандарта на T-SQL так же как нет стандарта на PL/SQL и другие диалекты. Зато есть худо-бедно стандарт на сам SQL и его-то и нужно придерживаться производителям SQL серверов.

Скажем, простой пример из моей практики: нужно было реализовать в MSSQL стандартную ф-цию перевода цисла в его словесное представление. Ф-ция давно была написана и отлажена на Delphi. Можно было подключить ее через DLL, но, по некоторым соображениям, пришлось перевести ее на T-SQL, потратив на это определенное время и усилия - какой смысл?.
В случае с Yukon и .NET-языка, мне достаточно написать эту ф-цию один раз и работать она будет быстрее, что существенно, если я захочу запихать ее в SELECT.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821456
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Yo!

Вы должны быть очччень хорошим папой
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821484
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeonidВозвращаясь к теме, я вот не пойму, что вы держитесь за T-SQL как надстройку? Чем лучше этот "клей" между SQL операторами, чем полнофункциональный язык, не пойму?

Это "клей" позволяет Вам быстро и эффективно реализовывать бизнес-логику в БД, где вся бизнес-логика - это цепь операций с множествами. Чем "полнофункциональный" язык будет выгодней в данном плане я лично не понимаю. Если еще вспомнить про динамический SQL и возможность без проблем с помощью его строить гибко настраивающуюся бизнес-логику на сервере, то и вообще тут я в компиляторах смысла не вижу.

LeonidЯ не со стороны рассуждаю. Мне очень часто приходится писать на T-SQL большие процедуры и я, поверте, знаю что говорю.
А я не со стороны могу заявить, что процедуры не могут быть сильно большими, как не могут быть сильно вложенными, с большим кол-вом переменных, циклов или переменных. Если это наблюдается, значит проблемы в проектировании БД.

авторНет стандарта на T-SQL так же как нет стандарта на PL/SQL и другие диалекты. Зато есть худо-бедно стандарт на сам SQL и его-то и нужно придерживаться производителям SQL серверов.
Что будем брать за стандарт - SELECT, INSERT, UPDATE, DELETE ? Долой рекурсивные запросы, долой времянки, долой триггера, ХП и т.д., так как у каждой РСУБД это свое ? Может тогда и долой транзакции, чтобы не путаться между блокировочниками, версионниками и особенностями их реализаций для каждой СУБД ?

LeonidСкажем, простой пример из моей практики: нужно было реализовать в MSSQL стандартную ф-цию перевода цисла в его словесное представление. Ф-ция давно была написана и отлажена на Delphi. Можно было подключить ее через DLL, но, по некоторым соображениям, пришлось перевести ее на T-SQL, потратив на это определенное время и усилия - какой смысл?.
В случае с Yukon и .NET-языка, мне достаточно написать эту ф-цию один раз и работать она будет быстрее, что существенно, если я захочу запихать ее в SELECT.
Скажем так - сумма прописью обычно реализуется на клиентском приложении и сие я могу только назвать извратом (без обид) :)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821549
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Скажем, простой пример из моей практики: нужно было реализовать в MSSQL стандартную ф-цию перевода цисла в его словесное представление. Ф-ция давно была написана и отлажена на Delphi. Можно было подключить ее через DLL, но, по некоторым соображениям, пришлось перевести ее на T-SQL, потратив на это определенное время и усилия - какой смысл?.
В случае с Yukon и .NET-языка, мне достаточно написать эту ф-цию один раз и работать она будет быстрее, что существенно, если я захочу запихать ее в SELECT.

на SQL, это дело можно реализовать так, чтобы работало достаточно производитльно. Плавал я в этих морях, знаю о чем говорю. Хотя это только часть задачи. Есть еще и валюты, и их склонения должны быть в этом случае написаны правильно. Типа одна тысяча пятьсот долларов 50 центов ) еще и справочник валют нужен...)) а справочник - это табличка в базе данных...
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821573
Фотография Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUSЭто "клей" позволяет Вам быстро и эффективно реализовывать бизнес-логику в БД, где вся бизнес-логика - это цепь операций с множествами. Чем "полнофункциональный" язык будет выгодней в данном плане я лично не понимаю.Да тем и будет выгоднее, что он полнофункциональный и операции с множествами ни куда не пропадут.

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

ASCRUSЧто будем брать за стандарт - SELECT, INSERT, UPDATE, DELETE ? Долой рекурсивные запросы, долой времянки, долой триггера, ХП и т.д., так как у каждой РСУБД это свое ? Может тогда и долой транзакции, чтобы не путаться между блокировочниками, версионниками и особенностями их реализаций для каждой СУБД?Ну почему долой? Почему?! Ни кто их у Вас не отбирает. Не передергивайте, пожалуйста! Вам просто заменяют "клей" на более универсальный. Хотите, пользуйтесь старым "клеем". Вы бы почитали сначала статьи от самого MS на сайте MSDN по поводу как это будет в Yukon, а потом бы уже кричали, что вам из этого нужно/не нужно. А то я боюсь, вы имеете поверхностное представление.

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

Это лишь частный, может и не лучший, пример интеграции полнофункционального языка в SQL. Гораздо более интересна перспектива более простого создания бизнес логики прямо на сервере.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821631
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я никогда и не утверждал, что это не нужно. Мы вроде как начали с того, что для начала было бы неплохо довести до ума то, что есть в MSSQL, а потом уже заниматься его расширением и интеграцией с другими продуктами ? И передергиваю не я, так как мой комментарий шел к Вашему высказыванию по поводу "Ну его TSQL, на C# писать выгоднее". Плохо, когда производитель ПО мечеться из стороны в сторону, периодически устраивая у себя революции, именно по этой причине я не люблю работать с продукцией MS и Borland, хотя "любить" и "работать" конечно же разные понятия.

авторГораздо более интересна перспектива более простого создания бизнес логики прямо на сервере.
Как я уже говорил выше, это вроде и сейчас возможно во многих РСУБД на Java, поэтому в встраивании такой возможности в MSSQL в 2005 году (если у MS опять накладок не случится) поводом восторгаться и радоваться не вижу, тем более утверждать насчет весомых аргументов над Ораклом.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821680
Фотография Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUSЯ никогда и не утверждал, что это не нужно. Мы вроде как начали с того, что для начала было бы неплохо довести до ума то, что есть в MSSQL, а потом уже заниматься его расширением и интеграцией с другими продуктами? И передергиваю не я, так как мой комментарий шел к Вашему высказыванию по поводу "Ну его TSQL, на C# писать выгоднее".
Да, мне как разработчику выгоднее.
Ну доведут они до ума T-SQL и что? Мне как разработчику все равно придется помнить кроме SQL, его к тому времени раздутую вплоть до ООП Transact-составляющую, а при переходе на ORACLE его раздутую PL-составляющую.

Хороший пример с VB, который сейчас лицензируют все кому не лень, и правильно делают. Те же Corel, AutoDesk встраивают в свои продукты поддержку VB в качестве "клея" - очень удобно для унифицированного скрипто-писания под Win.

ORACLE, кстати, на сколько мне известно, тоже будет поддерживать .NET
Возможно, правда, не так хорошо и тесно, как MSSQL.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821702
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нету стандарта SQL, нету. Нечего придерживаться. Т.е. стандарт-то есть, но ограничиваясь только им ничего не напишешь.
Короче, идея писать на бейсике, пользуясь только "стандартной частью" TSQL абсолютно утопична.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821733
Фотография Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivНету стандарта SQL, нету. Нечего придерживаться. Т.е. стандарт-то есть, но ограничиваясь только им ничего не напишешь.
Ну так плохо это, плохо. Вместо того, чтобы развивать стандарт SQL, каждый тянет одеяло на себя. Но подвижки есть тем не менее. ORACLE и тот к JOIN-ам пришел наконец-то.

MasterZivКороче, идея писать на бейсике, пользуясь только "стандартной частью" TSQL абсолютно утопична.
Да никто и не предлагает писать на "стандартной части" TSQL склеивая это бейсиком. Просто большую часть Transact-составляющей можно перенести на плечи .NET, а не развивать параллельно по сути еще один язык.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821839
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хотелось бы увидеть практический пример реализации хотя бы примитивной бизнес-логики: код на TSQL и аналогичный код на C#, где сразу бы в глаза бросались преимущества последнего. А пока рассуждения идут в пользу бедных, если бы да кабы :)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32821877
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MSDN - пример что C# хорошая замена TSQL:
Это у нас на C#:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
[SqlProcedure]
   public static void Product(out SqlInt32 value)
   {
      SqlCommand cmd = SqlContext.GetCommand();
      cmd.CommandText = "select intcolumn from tbl";
      SqlDataReader r = cmd.ExecuteReader();
      bool first = true;
      using (r) 
      {
         while (r.Read()) //skip to the next row
         {
            if (first)
            {
               value = r.GetSqlInt32( 0 );
               first = false;
            }
            else
            {
               value *= r.GetSqlInt32( 0 );
            }
         }
      }
   }

А это на TSQL:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
create procedure TSQL_ProductProc (@product int output)
as
begin
   declare @sales int
   declare c insensitive cursor for select intcolumn from tbl
   open c
   fetch next from c into @sales
   
   if @@FETCH_STATUS =  0   
   set @product = @sales  
   
   while @@FETCH_STATUS =  0 
   begin
   fetch next from c into @sales
   set @product = @product * @sales
   end
   
   close c
   deallocate c
end
Ну надо же - по кол-ву и читабельности кода почти то же самое. Разве что в версии ХП C# еще CLR нужно не кисло знать в плане правильной работы с MSSQL. А давайте попробуем посмотреть, не смухлевали ли в MSDN и напишем свою версию процедуры:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
create procedure TSQL_ProductProc (@product int output)
as
begin
  set @product =  1 

  update tbl
  set @product = @product * intcolumn
end
Гм, что то тут не так. Можно сказать, что в TSQL не всегда так выкрутиться можно ? Угу, можно. Зато в ASA WatcomSQL и выкручиваться не надо. Берем первый попавшийся пример из BOL - в данном случае демонстирующий организацию нарастающих сумм в запросах через OLAP функции:
Код: plaintext
1.
2.
3.
4.
5.
6.
SELECT dept_id, emp_lname, start_date, salary,
SUM(salary) OVER (PARTITION BY dept_id
ORDER BY start_date
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS "Sum_Salary"
FROM employee
WHERE state IN ('CA', 'UT', 'NY', 'AZ') AND dept_id IN ('100', '200')
ORDER BY dept_id, start_date;
а вот и результат:
dept_idemp_lnamestart_datesalarySum_Salary100'Whitney''1984-08-28'45700.00045700.000100'Cobb''1985-01-01'62000.000107700.000100'Shishov''1986-06-07'72995.000180695.000100'Driscoll''1986-07-01'48023.690228718.690100'Guevara''1986-10-14'42998.000271716.690100'Wang''1988-09-29'68400.000340116.690100'Soo''1990-07-31'39075.000379191.690100'Diaz''1990-08-19'54900.000434091.690200'Overbey''1987-02-19'39300.00039300.000200'Martel''1989-10-16'55700.00095000.000200'Savarino''1989-11-07'72300.000167300.000200'Clark''1990-07-21'45000.000212300.000200'Goggin''1990-08-05'37900.000250200.000
Гм - тут ни курсоров, ни циклов, ни переменных, а ведь поди считаются нарастающие по каждой указанной группе. Вопрос на засыпку - а будет ли код на C# выглядеть так же эффективно, как этот запрос ? А не легче ли это было встроить в TSQL и не навязывать людям .NET ?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32822128
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Триггеры before и другие обсуждались вот тут:

http://www.sql.ru/forum/actualthread.aspx?tid=27979

2 Leonid

>Можно было подключить ее через DLL, но, по некоторым соображениям, пришлось перевести ее на T-SQL, потратив на это определенное время и усилия - какой смысл?

Действительно, нет смысла. Может все-таки нужно было подключить через DLL? DLL это такой же механизм для интеграции приложений (тоже революционная технология, много шума было когда-то), как сейчас .НЕТ.

После выхода Юкона (если вдруг) тоже можно будет сказать: можно было написать на C#, но, по некоторым соображениям, пришлось перевести ее на T-SQL. "Некоторые соображения", как известно, от языка программирования не зависят.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32822143
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>>Мне как разработчику все равно придется помнить кроме SQL, его к тому времени раздутую вплоть до ООП Transact-составляющую, а при переходе на ORACLE его раздутую PL-составляющую.

Ну и что? От разработчиков всегда требуется что-то помнить. Такова жизнь...
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32822145
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> Скажем, простой пример из моей практики: нужно было реализовать в MSSQL стандартную ф-цию перевода цисла в его словесное представление. Ф-ция давно была написана и отлажена на Delphi. Можно было подключить ее через DLL, но, по некоторым соображениям, пришлось перевести ее на T-SQL, потратив на это определенное время и усилия - какой смысл?.

Вот потому, что такие функции на сервер тащить не стоит, и не следует включать .NET в MSSQL. Потому, что все скриптописатели сразу начнут тянуть все своё незаменимое творчество на сервер. А смысл?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32822171
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
www.fun4me.narod.ruВот потому, что такие функции на сервер тащить не стоит, и не следует включать .NET в MSSQL. Потому, что все скриптописатели сразу начнут тянуть все своё незаменимое творчество на сервер. А смысл?
Мне вот интересно другое - MS же должна понимать, что развязывая руки кодерам в MSSQL и давая им такое мощное средство, как C# и CLR, она просто ставит под удар такие характеристики, как надежность, скорость и безопасность. Уже видны толпы радостно потирающих руки кодеров, с высказываниями типа - "Наконец то мы в БД все реализуем как привыкли в Access/Delphi/etc". Исходя из этого можно ожидать на сегменте баз данных MSSQL необычайно мощного всплекса криво реализованных БД, собственных велосипедов обработки и хранения данных в БД (вот уж где будет соблюдение "одного стандарта программирования"), вирусов хранимых-процедур и много чего еще интересного. С моей точки зрения для MS , которая специально в те же UDF ввела множество ограничений для борьбы с велосипедистами в MSSQL 2000, такая смена политики выглядит довольно странно.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32822275
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А ведь так можно и Mono в MySQL запихать! Вот зверь получится!!!
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32823080
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вообще, согласен с мнением, что CLR в SQL Server - это кратчайший путь к созданию кривых в общей массе баз данных.

меня не удивляет то, что некоторые пытаются сделать все на уровне приложения, а не БД. Это говорит лишь о слабом знании самого сервера БД, его возможностей. Я думаю, наивно было бы полагать, что доморощенный Кулибин сделает построит более эффективный план запроса, чем оптимизатор сервера БД.

С другой стороны внесение возможностей CLR, Java внутрь сервера БД в определенных случаях может значительно помочь в том случае, когда у архитектора проекта есть голова на плечах.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32823228
Фотография Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUSC# выглядеть так же эффективно, как этот запрос ? А не легче ли это было встроить в TSQL и не навязывать людям .NET ?
Ну, во-первых, вам ни кто ни чего не навязывает. Так же как и java в ORACLE. Не изображайте из себя несчастного обманутого потребителя. Будете вы пользоваться этим или нет - это ваше дело.
Во-вторых, MS сама рекомендует без надобности CLR не использовать:
Even before CLR support was introduced in SQL Server, it has always been important to recognize that database applications should use the query language as much as possible. Database applications should take advantage of the set-oriented query processor and only resort to procedural programming for expressing logic that cannot be expressed within the query language.

Если вы внимательно читали статью, из которой приводите пример, то там много пояснений где использование CLR оправдано, а где нет.
Кстати, к слову, пример для ASA WatcomSQL куда менее читабелен, чем трюк на MSSQL и даже его менее эффективный аналог на C#.

www.fun4me.narod.ruВот потому, что такие функции на сервер тащить не стоит, и не следует включать .NET в MSSQL. Потому, что все скриптописатели сразу начнут тянуть все своё незаменимое творчество на сервер. А смысл?Знаете, надо еще разобраться, кто есть скриптописатель? Программист на С/C++/C#/Delphi или T-SQL/PL-SQL ;)

ASCRUSМне вот интересно другое - MS же должна понимать, что развязывая руки кодерам в MSSQL и давая им такое мощное средство, как C# и CLR, она просто ставит под удар такие характеристики, как надежность, скорость и безопасность. Уже видны толпы радостно потирающих руки кодеров, с высказываниями типа - "Наконец то мы в БД все реализуем как привыкли в Access/Delphi/etc"... Глупость какая... А еще напишите сюда про толпы мрачных T-SQL программистов, оставшихся без работы, потому что все теперь можно реализовать на C#. ;)

ASCRUSиз этого можно ожидать на сегменте баз данных MSSQL необычайно мощного всплекса криво реализованных БД, собственных велосипедов обработки и хранения данных в БД (вот уж где будет соблюдение "одного стандарта программирования"), вирусов хранимых-процедур и много чего еще интересного.Опять глупость какая-то. Кривость БД не пропорциональна заложенным в сервер возможностям. В таком случае, самые кривые решения должны быть на ORACLE ;)

Я, например, уверен, что с интеграцией .NET в MSSQL, будет проще создание многозвенных БД на базе MSSQL. Сервер приложений будет гораздо легче интегрировать с БД. По сути он там может и находится.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32823293
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeonidЯ, например, уверен, что с интеграцией .NET в MSSQL, будет проще создание многозвенных БД на базе MSSQL. Сервер приложений будет гораздо легче интегрировать с БД. По сути он там может и находится.
Хм. По мне, идея интеграции AS в БД несколько сомнительна. Идея "многозвенности" - как раз в том, что AS - это приложение, работающее с БД, и единственное, видимое "снаружи".

Другой вопрос - что этим путем можно будет легко создавать "БД, которые на самом деле не только БД" - к примеру, те же view, содержимое которых ограничено правами пользователя и рассчитывается с использованием возможностей appserver-а.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32823325
?
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
?
Гость
LeonidОпять глупость какая-то. Кривость БД не пропорциональна заложенным в сервер возможностям. В таком случае, самые кривые решения должны быть на ORACLE ;)Именно такое впечатление и складывается.
На MS SQL курсоры медленны - все стараются обходится без них. В ORACLE - лепят где нужно и где не нужно.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32823365
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeonidНу, во-первых, вам ни кто ни чего не навязывает. Так же как и java в ORACLE. Не изображайте из себя несчастного обманутого потребителя. Будете вы пользоваться этим или нет - это ваше дело.
Да без проблем. Только не надо тут это тогда превозносить, как этакое новое чудо от MS.

LeonidКстати, к слову, пример для ASA WatcomSQL куда менее читабелен, чем трюк на MSSQL и даже его менее эффективный аналог на C#.
К слову сказать если внимательно прочитать в том приведенном примере, то окажется, что это не аналог "трюка на MSSQL", а пример, демонстрирующий более сложные приемы использования запросов, которые на текущий момент просто в MSSQL недоступны. Так что прежде чем меня обвинять в повсевместной глупости потрудитесь внимательно читать то, что Вам пишут.

Leonid www.fun4me.narod.ruВот потому, что такие функции на сервер тащить не стоит, и не следует включать .NET в MSSQL. Потому, что все скриптописатели сразу начнут тянуть все своё незаменимое творчество на сервер. А смысл?Знаете, надо еще разобраться, кто есть скриптописатель? Программист на С/C++/C#/Delphi или T-SQL/PL-SQL ;)
Однозначко кодеры и есть скриптописатели, после "мук творчества" которых частенько волосы встают дыбом, когда глядишь на их код в БД.

LeonidГлупость какая... А еще напишите сюда про толпы мрачных T-SQL программистов, оставшихся без работы, потому что все теперь можно реализовать на C#. ;)
Да нет - толпы еще более мрачных, чем ранее DBA, которым ранее приходилось встречаться только с кривыми реализациями на TSQL, а теперь они в придачу получат C# и VB.NET (были цветочки, станут ягодки).

LeonidКривость БД не пропорциональна заложенным в сервер возможностям. В таком случае, самые кривые решения должны быть на ORACLE ;)
Угадали - именно так и есть, самые кривые и вгоняющие в обморок решения я видел именно на Оракле, что и говорит о его многофункциональности и последствиях излишне любящих творчество.

LeonidЯ, например, уверен, что с интеграцией .NET в MSSQL, будет проще создание многозвенных БД на базе MSSQL. Сервер приложений будет гораздо легче интегрировать с БД. По сути он там может и находится.
Вот про такие мысли я и говорил. Вы случайно не заметили разницу между назначением хранимой процедуры на C# для MSSQL и парадигмой 3-его звена ?

P.S. А вообще не понимаю, чего так горячиться и обвинять других в глупости ? Неужели Вы думаете, что я настолько туп и недальновиден, что не вижу выгод при использовании ООП языков в БД ? В данном случае мне не интересны преимущества, их и так понимает любой граммотный проектировщик БД, мне гораздо интереснее последствия :)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32823500
??
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
??
Гость
?На MS SQL курсоры медленны - все стараются обходится без них. В ORACLE - лепят где нужно и где не нужно.

От обратного - в MSSQL все лепят времянки где нужно и не нужно ;-) И не понимают, как в Оракле большинство обходится без них.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32823515
Фотография Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUSДа без проблем. Только не надо тут это тогда превозносить, как этакое новое чудо от MS.Я не превозносил, а лишь говорил, что у MS это, возможно, получится удачнее, чем у конкурентов.

ASCRUSОднозначко кодеры и есть скриптописатели, после "мук творчества" которых частенько волосы встают дыбом, когда глядишь на их код в БД.Вы видели мой код на T-SQL или код наших сотрудников, чтобы так утверждать?
Значит вы видели плохой код, плохих SQL программистов, применяющих dBase подходы при работе с SQL Server-ами.
Так что попрошу не обобщать. И, потом, ни чего особенно уж сложного в стандартном SQL нет, а необходимость знания реляционной модели при работе с SQL-Server-ами никто не отменит.
А вот как ни крути, а на скрипт все же больше похожа Transact или PL - составляющие, чем полнофункциональный язык ;)

ASCRUSДа нет - толпы еще более мрачных, чем ранее DBA, которым ранее приходилось встречаться только с кривыми реализациями на TSQL, а теперь они в придачу получат C# и VB.NET (были цветочки, станут ягодки).
Ну зачем так мрачно? Да и потом, по большому счету, не DBA это дело лезть в реализацию конкретной БД, а уж тем более ее править. Вот как раз наши "доморощенные DBA-Кулибины" очень любят это делать, иногда даже толком не зная, зачем и почему сделано так-то и так-то.
Понятно, что Российские реалии - это особый случай, но кривая реализация - это просто "кривая реализация" без относительно того, кем и не чем она сделана.

ASCRUSУгадали - именно так и есть, самые кривые и вгоняющие в обморок решения я видел именно на Оракле, что и говорит о его многофункциональности и последствиях излишне любящих творчество.
Сам видел кривые решения на Oracle, ну и что? От перехода в более узкие рамки MSSQL или другой БД они что распремятся что ли?
Вы и сами знаете, что кривость не в ORACLE, а в головах разработчиков. Ну посади ты их на другую БД они и там все криво наваяют. Зато на ORACLE - это круто! ;) Боюсь, это тема для другой ветки ;)

ASCRUSВот про такие мысли я и говорил. Вы случайно не заметили разницу между назначением хранимой процедуры на C# для MSSQL и парадигмой 3-его звена ?
А я и не собирался запихивать AS в хранимую процедуру.

ASCRUSА вообще не понимаю, чего так горячиться и обвинять других в глупости ?Давайте не будем горячится, кто против, тем более нам с вами делить особенно не чего ;)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32823532
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> И, потом, ни чего особенно уж сложного в стандартном SQL нет, а необходимость знания реляционной модели при работе с SQL-Server-ами никто не отменит.

А в С++ разве что-то особенно сложное есть?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32823607
Фотография Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
www.fun4me.narod.ruА в С++ разве что-то особенно сложное есть?Вы сами знаете ответ. Точно так же нужны знания и практика ;)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32823647
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
есть неоспоримый факт что существует достаточно большая часть программеров которые совершенно не вникает в работу субд. мало того это от него специально скрывают различные фреймворки и корпоративные буилдеры. эти люди пишут серийные системы обслуживающие крупнейшие канторы, т.е. их системы в разы комплекснее чем системы большинства из вас. да есть проблема производительности у таких изделий, но при определеных размерах проэкта это решается грубой силой (железом).
короче мысль в том что те кто и так логику вынес на апп-сервер, получит бонус в виде переноса оной на ближе к уровеню субд и получив еще пару процентов к скорости, а те кто бьется за каждый запрос, так и будут использовать T-SQL (PL/SQL).
просто как видно по ораклу он потехоньку забивает на pl/sql (7 лет косметические изменения) и теперь очень медлено его развивает, в то время как 10gR2 жаба продвинута до версии 1.4
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32823670
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo!есть неоспоримый факт что существует достаточно большая часть программеров
Этот баян мы недавно обсуждали...
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32824391
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 ASCRUS

>Мне вот интересно другое - MS же должна понимать, что развязывая руки кодерам в MSSQL и давая им такое мощное средство, как C# и CLR, она просто ставит под удар такие характеристики, как надежность, скорость и безопасность. Уже видны толпы радостно потирающих руки кодеров, с высказываниями типа - "Наконец то мы в БД все реализуем как привыкли в Access/Delphi/etc". Исходя из этого можно ожидать на сегменте баз данных MSSQL необычайно мощного всплекса криво реализованных БД, собственных велосипедов обработки и хранения данных в БД (вот уж где будет соблюдение "одного стандарта программирования"), вирусов хранимых-процедур и много чего еще интересного.

Не беспокойтесь, ничего не изменится. Посмотрите на Ваш же пример:

SqlCommand cmd = SqlContext.GetCommand();
cmd.CommandText = "select intcolumn from tbl";
SqlDataReader r = cmd.ExecuteReader();


На каждый чих (select, insert, update) - 3 строчки. Синтаксис запроса на этапе компиляции никак не проверяется. Так много не напишешь. Так что получится то же, что и с джавой в других SQL серверах: поиграются и вернуться к TSQL. Это кто поумнее и кому нужно работу делать, а кто попроще будут бороться с C#.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32824515
g
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
g
Гость
большинство высказываний защитников ORACLЕ находиться на уровне эмоций: SQL-Server - отстой,
а Б. Гейтс - козел по определению, следовательно пользоваться его продуктами не будем, а кто
пользуется - лохи позорные.

Видали мы таких - рвут глотку, что винда - тормозная и незащищенная по сравнению с *nix , а сами
с ХР не слазят.

Если вы привыкли к oracle и не хотите пользоваться MSSQL, которая по сути не лучше и не хуже,
так честно так и скажите, а не наезжайте на новые возможности системы, только потому, что
ненавидите microsoft.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32824538
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну кто сказал что мы ненавидим M$? В принципе - хорошая ОС. Но вот политика M$ в области продвижения своего ПО не всегда чистоплотна (хотябы в отношении Линукс). У ПО от M$ полно недостатков, в некоторых аспектах оно хуже и отстает от ПО других производителей, которые разрабатывают софт на их же платформе. Конечно же M$ никуда не денется ближайшие годы, но однако потесниться придется, причем основательно.
Время покажет.
--
Да здравствует Линукс!
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32824696
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 g

>большинство высказываний защитников ORACLЕ находиться на уровне эмоций: SQL-Server - отстой, а Б. Гейтс - козел по определению, следовательно пользоваться его продуктами не будем, а кто пользуется - лохи позорные.

Это аргументированно, с выдержками и цитатами и без лишних эмоций.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32824704
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenman Конечно же M$ никуда не денется ближайшие годы, но однако потесниться придется, причем основательно.
Время покажет.
Дык время то вроде как раз наоборот показывает - MS остальных теснит :)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32824760
g
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
g
Гость
2 c127

Мимопроходящий
Visual Basic форева!!!!
Ураааа!!!
Заменим Басиком SQL !!!!
Ураааа 2 раза!!!




nik_xНе доконца мысль излил...
Ударим Пивом по M$-рожью и разгильдяйству !!!


Yo!мда .. меняем mssql на mysql а оракл на mssql и понимаем какую чушь пороли :)


ЗЫ. mssql это пока единственная субд добившееся действительно впечатляющих результатов в области секурити - это единственая субд с вирусами на пару дней вывела из строя целый регион. такое еще никому не удавалось.

nik_x
Ну а насчет PL/SQL, коль не дошло, то:
ПЛОХОМУ ТАНЦОРУ - ЯЙЦА МЕШАЮТ !


Достаточно ?


2 gardenman

Если кто не знает, то Unix появился много раньше Windows. Его первая версия вышла аж в 1971 г., и
в свое время он (и его разновидности) доминировали в мире.
Windows существует только около 10 лет (не считая 3.1), и является абсолютным лидером все эти 10 лет.
То-же самое касается ДОС, который был ВЕЗДЕ.
Так что Microsoft никуда не денется, Linux конечно тоже в небытие не впадет, но и в лидеры никогда
не выбьется. Да и что такого там с ценовой политикой ? Посмотрите сначала сколько стоит Red Hat Linux,
а людей, которые сами скачивают бесплатные дистрибутивы и компилят их, не так много, я например себе
занятие поинтереснее найду.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32824794
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
2g

я смотрю вы тут новенький, поэтому чтоб не выглядеть дурачком потрудитесь просмотреть соседние топики, там достаточно подробно рассписаны все аргументы, по всем вопросам. начиная от уровней изоляции заканчивая кластерами. повторять одно и то же в каждом топике большинству задолбало, хотя упорно пару лет это делали.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32824928
Фотография hell
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
g - забудте в этой ветке про Linux. На данный момент обсуждаемые СУБД имеют свои излюбленные платформы MSSQL - Win2k, 2k3 Oracle = unix(solaris, ..). Oracle на Linux держат в 99% для тестовых систем. А тот же Solaris не такая пионерская разработка, как Вы пытаетесь нам преподнеси.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32824957
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hell
Oracle на Linux держат в 99% для тестовых систем.

Наша фирма начала ставить закачикам Оракл на Linux. Т.е. раньше были видны, но при установке новой версии инф. системы ставят Linux. Ну и для разработки на фирме 2 сервера на Linux, Один старый на Виндах. Правда много ораклов на клиентских компах на виндах - потому, что на серваке возникают неприятные накладки - один снес что-то из БД, а там были разрабатываемые объекты коллеги (у нас несколько разных проектов). У заказчиков для БД Одна Open VMS, один UNIX - это требования заказчика. Один заказчик раньше перешел с UNIX на Винды из-за того, что передали систему для администрирования тамошним АСУ-бщикам, а те не знают UNIX и потредовали перевода на Винды серверов. Хорошо, что Ораклу по барабану ОС. Конечно, если не обращать внимания, что там свои баги могут быть. Но вроде пока не напрягает.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32824959
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfo hell
Oracle на Linux держат в 99% для тестовых систем.

Наша фирма начала ставить закачикам Оракл на Linux. Т.е. раньше были видны, но при установке новой версии инф. системы ставят Linux. Ну и для разработки на фирме 2 сервера на Linux, Один старый на Виндах. Правда много ораклов на клиентских компах на виндах - потому, что на серваке возникают неприятные накладки - один снес что-то из БД, а там были разрабатываемые объекты коллеги (у нас несколько разных проектов). У заказчиков для БД Одна Open VMS, один UNIX - это требования заказчика. Один заказчик раньше перешел с UNIX на Винды из-за того, что передали систему для администрирования тамошним АСУ-бщикам, а те не знают UNIX и потредовали перевода на Винды серверов. Хорошо, что Ораклу по барабану ОС. Конечно, если не обращать внимания, что там свои баги могут быть. Но вроде пока не напрягает.

Это как это много оракла на клиентских компах? Каждому разработчику по базе что-ли? Для тестирования и сборки релизов у вас должна быть отдельная база, где у разработчиков прав нет.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32824979
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
killed
Это как это много оракла на клиентских компах? Каждому разработчику по базе что-ли? Для тестирования и сборки релизов у вас должна быть отдельная база, где у разработчиков прав нет.

На клиентских для разработки своих задач. Но там по одной-две БД. Не у всех разработчиков конечно. А у меня так еще и дома. На серверах несколько БД по разным проектам. Например, эти празники для тестирования и настроек закчиваю в одну такую в две таблы по 30 миллионов записей. Конечно, такого на клиентском компе нет возможности провернуть. Кроме того, мы и есть разработчики - т.е. и разработчики БД. К сожалению, у заказчика реализовали уже кластер с рейдами, а этого нет сейчас на фирме. Те кто проектировали торопились или что (не дотестировали), но теперь там у заказчика что-то тормозит, а мне дали задание решить этот вопрос. Так что тестирование идет не на полном аналоге. Т.е. у нас много баз для тестирования, а той что надо (в плане физической реализации) для выполнения моего задания нет. Возможно, придется еще ехать самому к заказчику и там разбираться, а очень неохота, и денег фирмы жалко (итак этим летом не было большой премии).
Одно дело, то что в книгах написано про то как должно быть, а другое то с чем приходится сталкиваться в реальности.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32824987
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfo killed
Это как это много оракла на клиентских компах? Каждому разработчику по базе что-ли? Для тестирования и сборки релизов у вас должна быть отдельная база, где у разработчиков прав нет.

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

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

По поводу rac, raid и т.д. А откуда уверенность, что проблема именно в "физике"? Это мне кажется вообще аутскоп для разработчиков. Я бы к примеру для начала попросил клиента выслать экспортированную статистику. Применить ее на базе (опять таки на базе для целей QA) и протестировать функционал. В любом случае, сделать "полный аналог" - имхо нереальная задача.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32825018
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
killed
Если честно, это все малоубедительно. По-моему опыту, чем больше исключений из правил - тем больше хаоса при разработке. А еще я убежден, что грамотный разработчик, если он считает себя профессионалом, будет работать в рамках общего полиси, не изобретая велосипед. Почему? Потому что он знает, что съэкономит себе массу времени. Другое дело, когда такого полиси нет у компании, но это уже ваша вина.

Разумеется это не убедительно. Но что делать? Просто у разных проектов разные требования. В одних случаях это проходило, а в других нет. Если бы я вел тот проект, то перезаложился бы на проверках. Но что значит полиси, когда каждый проект по своему уникален? На то он и проект. Другое дело выполнение некоторых общих рекомендаций известных методологий по проектированию ИС. Но это решение руководителя конкретного проекта. У фирмы есть стандарты, но в тестировании явно они кое-что упустили. А меня никто не спрашивал - мое дело выполнять задания, а не рассуждать о том как надо было все делать. Хотя протолкнуть в стандарты полномасштабное тестирование БД буду пробовать после этого случая.

killed
По поводу rac, raid и т.д. А откуда уверенность, что проблема именно в "физике"? Это мне кажется вообще аутскоп для разработчиков. Я бы к примеру для начала попросил клиента выслать экспортированную статистику. Применить ее на базе (опять таки на базе для целей QA) и протестировать функционал. В любом случае, сделать "полный аналог" - имхо нереальная задача.



Я имел в виду, что если бы тестирование было один к одному, то я бы чувствовал себя более уверенно. Я бы проверил те исправления на реальном варианте, и их бы выполнили удаленно или те кто туда ездит. А так может не повезти и там окажется что-то другое. Может и не с Ораклом связанное, наряду с причинами Оракловыми. Например, что-то левое ресурсы хапает. То что физика играет роль для тестирования достойно учета. Например, уже есть показания перенести журналы повторного выполнения лучше на другой диск на этом серваке, а там рэйды и таких ожиданий может и не быть. Там показатели I/O другие - много выше. Конечно, все что касается приложения будет проверено, но пойдут ли на исправления не известно. Например, уже есть подозрения на чрезмерные коммиты.
Что касается статиситки, то ее сбор там еще надо организовать. Кроме того, для выявление конкретных причин нужно отлавливать чего ожидает сессия в момент, когда тормоза явно видны. Ну и все такое. Возможно все это придется сделать (там организовывать сбор статистики и ждать когда тормознется), после того как въеду в особенности работы БД в этом проекте.
Но очень хочется, чтобы обошлось без этого.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32825851
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 g

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

Вполне нормальные аргументы, если не лениться читать. Я тоже объяснил почему считаю что C# в качестве языка программирования SQL серверов не приживется. Хранение запросов в виде строк с проверкой синтаксиса и пр. во время исполнения работает только когда таких запросов относительно немного. На SQL серверах запрос - основное средство работы, строк с запросами чуть ли не больше, чем строк без запросов. Кроме того еще, предлагается увеличить это количество втрое. Поэтому должен быть специализированный язык или хотя бы препроцессор как у ДБ2, оракла и сайбейза, а джава или C# для этой задачи неудобны.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32825934
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надо для СУБД вместо CLI использовать какой-нибудь DPLI /*Data Processing Lanuage Infrastructure*/, который должен быть расширнием CLI и в которм будут хранится разобранные запросы. Тогда быстро работать всё будет. А если DPLI подключить к Mono и присобачить к MySQL, то хранимые процедуры будут переносимы.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32834831
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
позвольте и мне пару ложек.
Вот тут мнения такие наблюдаются:

авторЗачем перегружать СУБД излишней бизнес-логикой, для этого есть сервера приложений...
Правильно, незачем ИЗЛИШНЕЙ перегружать, но существует огромное количество примеро в которых java stored procedure намного удобнее чем PL/SQL- вариант.
Возьмем ORDER/Detail.
Что бы сохранить счет оптимальным способом (одним вызовом):
1) для PL/SQL варианта понадобиться сериализовать объект в xml, вызвать sp на PL/SQL, там "разобрать" xml и сделать соответствующие инсерты в мастер и деталь.
2) для варианта с java вы работаете в терминах объектов и на стороне клиента, и на стороне сервера приложения и на стороне сервера СУБД.
Поэтому если у вас плоский объект, возможно выбор будет в пользу PL/SQL, если же иерархический - то он прямой кандидат для реализации CRUD- операций на java.

Т.е. я что хочу сказать? То, что никто никогда не убеждал никого в том что перенос ВСЕЙ бизнес логики на сервер СУБД есть хорошо.
Но вот перенос бизнес-логики относящейся к CRUD-операциям на сторону СУБД безусловно способствует и пониманию того как работает база, и сокращению сроков разработки (в случае использования java на стороне СУБД), и сопровождению.
Так что поддержка .NET в mssql - это шаг в правильном направлении, который даст получить схожие возможности по сравнению с существующими СУБД с поддержкой Java.

авторJava мешается под ногами, PL/SQL вполне достаточен для реализации бизнес-логики на сервере.
Ничего она (Java) не мешается, Oracle-у уж точно :), а что касается Sybase дык писать нужно лучше чтоб под ногами java не мешалась.
И еще... как думаете почему в Oracle Lite процедуры и триггеры можно писать только на Java и никакого PL/SQL там нет?
Громоздок он слишком оказался для встраивания в мобильные СУБД (видимо)...

Относительно YUKON-а могу лишь надеяться на то, что дай бог нам получить хотя бы такую же функциональность/возможности которые есть в ORACLE 8i.
Так что ВЕСОМЫЙ под сомнением.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32835302
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ДынникВозьмем ORDER/Detail.
Что бы сохранить счет оптимальным способом (одним вызовом):
1) для PL/SQL варианта понадобиться сериализовать объект в xml, вызвать sp на PL/SQL, там "разобрать" xml и сделать соответствующие инсерты в мастер и деталь.
2) для варианта с java вы работаете в терминах объектов и на стороне клиента, и на стороне сервера приложения и на стороне сервера СУБД.
Поэтому если у вас плоский объект, возможно выбор будет в пользу PL/SQL, если же иерархический - то он прямой кандидат для реализации CRUD- операций на java.

Ооопс. А вот для варианта 2 (java) внутри логика разве не будет как и варианте 1 разбирать переданный для расширенной ХП обьект по косточкам и делать соотвествующие инсерты/апдейты в мастер и детайл ? А чем не устраивает стандартно для клиента открыть транзакцию, записать мастер, записать детайл, подтвердить транзакцию ? Ну а если даже уж хочется оптимальным (?) способом, то кто мешает сделать такую ХП:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
CREATE PROCEDURE sp_Master_Detail_Insert_Update (
  IN @xml xml
)
BEGIN
  INSERT INTO master ON EXISTING UPDATE WITH AUTO NAME
    SELECT *
    FROM OPENXML(@xml, '/master')
    WITH (
      id_master int '@id_master', 
      name char( 50 ) '@name'
    );

  INSERT INTO detail ON EXISTING UPDATE WITH AUTO NAME
    SELECT *
    FROM OPENXML( @xml,'/master/detail')
    WITH (
      id_master int '../@id_master', 
      id_detail int '@id_detail', 
      value int '@value'
    );
END;
Теперь клиент спокойно может одним вызовом заносить данные:
Код: plaintext
1.
2.
3.
4.
5.
6.
CALL sp_Master_Detail_Insert_Update ('
  <master id_master="1" name="Test record">
    <detail id_detail="1" value="100"/>
    <detail id_detail="2" value="200"/>
    <detail id_detail="3" value="300"/>
  </master>
');
Так же при желании на эту процедуру можно сделать веб-сервис и использовать его в HTTP протоколе или SOAP. Плюс можно даже в другой удаленной СУБД ее организовать как удаленную процедуру вызовом через стандартные инет-протоколы:
Код: plaintext
1.
2.
CREATE PROCEDURE sp_Master_Detail_Insert_Update ( @XML xml )
URL 'HTTPS://HostName/service_Master_Detail_Insert_Update'
TYPE 'SOAP:RPC'
Как видно и без Java мы прекрасно работаем с XML, веб-сервисами и любыми нужными нам фичами.

Роман ДынникНичего она (Java) не мешается, Oracle-у уж точно :), а что касается Sybase дык писать нужно лучше чтоб под ногами java не мешалась.
Дык мы и стараемся на Sybase писать так, чтобы Java родимая не мешалась, пользуясь только стандартными и неплохими возможностями WatcomSQL, без загрузки сервера кушающей память JVM :)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32835399
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторА чем не устраивает стандартно для клиента открыть транзакцию, записать мастер, записать детайл, подтвердить транзакцию ?
Тем что делается несколько вызовов и как следствие - старт транзакции на стороне среднего звена/клиента вместо того что бы стартануть на сервере с последующими возможными проблемы с deadlock-ми.
Как вам (100+1) вызов на сохранение счета со 100 позициями?

авторНу а если даже уж хочется оптимальным (?) способом, то кто мешает сделать такую ХП:
Никто не мешает, я же об этом и говорил. И сам xml активно пользую.
Но XML вы этот как получите? Нужно на стороне клиента сеарелизовать java-объект или вручную по объекту собрать XML, правильно? А в случае java-процедуры вы передаете объект без всяких усилий со стороны кода клиента.
И второе повышается читабельность кода на стороне СУБД а следовательно и качество поддержки, но это уже на вкус.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32835424
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JVM кушает 50М
для нормального сервака - это копейки.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32835448
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>>Никто не мешает, я же об этом и говорил. И сам xml активно пользую.
Но XML вы этот как получите? Нужно на стороне клиента сеарелизовать java-объект или вручную по объекту собрать XML, правильно? А в случае java-процедуры вы передаете объект без всяких усилий со стороны кода клиента.
<<


В .NET через SOAP объекты точно так же передаются абсолютно без всяких усилий со стороны разработчика клиентского приложения. А объект по любому сериализовать придётся - что при передаче через RMI, что при передаче через SOAP.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32835492
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
В .NET через SOAP объекты точно так же передаются абсолютно без всяких усилий со стороны разработчика клиентского приложения.
Тут пока про яву шорох поднялся.
авторА объект по любому сериализовать придётся - что при передаче через RMI, что при передаче через SOAP.
Мы говорим не про автоматическую/полуавтоматическую сериализацию (в случае .NET) через SOAP или RMI а про передачу объекта в процедуру через "строковый" параметр XML. Вот чтоб в этот строковый параметр значение(объект в виде XML) запихнуть и нужны усилия со стороны разработчика.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32835513
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ДынникМы говорим не про автоматическую/полуавтоматическую сериализацию (в случае .NET) через SOAP или RMI а про передачу объекта в процедуру через "строковый" параметр XML. Вот чтоб в этот строковый параметр значение(объект в виде XML) запихнуть и нужны усилия со стороны разработчика.
Минуточку - так я и привел пример процедуры в СУБД, которая элементарно превращается в SOAP-процедуру, с которой клиентское приложение может работать через тот же 80 порт на получение и передачу данных, вообще не используя никаких ODBC, JDBC, ADO.NET и прочего. А с клиентских приложений по моему все кому не лень могут с XML и веб-сервисами работать.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32835621
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор через тот же 80 порт
работа с сервером ч/з HTTP/S - это еще одна ОЧЕНЬ длинная песня, тут можно и про безопасность тему развить и производительность сравнить и про целесообразность погорорить...

Я еще пример приведу. Допустим для какого то класса у вас глубина наследования равная 5.
Соответственно на сервере, если CRUD в слое хп вам надо выполнить:
sp_Ins5(@xml)
-sp_Ins4(@xml)
-sp_Ins3(@xml)
-sp_Ins2(@xml)
-sp_Ins1(@xml)
т.е. из хп5 вызывается хп4, из хп4 - хп3 и т.д. до 1-го уровня
и в каждой процедуре делать OPENXML. Как вы думаете, с производительностью все нормально будет?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32835843
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Дынник автор через тот же 80 порт
работа с сервером ч/з HTTP/S - это еще одна ОЧЕНЬ длинная песня, тут можно и про безопасность тему развить и производительность сравнить и про целесообразность погорорить...

Я еще пример приведу. Допустим для какого то класса у вас глубина наследования равная 5.
Соответственно на сервере, если CRUD в слое хп вам надо выполнить:
Код: plaintext
1.
2.
3.
4.
sp_Ins5(@xml)
 -sp_Ins4(@xml)
   -sp_Ins3(@xml)
    -sp_Ins2(@xml)
      -sp_Ins1(@xml)
т.е. из хп5 вызывается хп4, из хп4 - хп3 и т.д. до 1-го уровня
и в каждой процедуре делать OPENXML. Как вы думаете, с производительностью все нормально будет?
Ну во первых кто мешает вызывать просто sp_Ins5(@xml), передавая туда сразу все аттрибуты класса и его предков ? Во вторых Вы пытаетесь на РСУБД наложить ООП, а при моем подходе это просто ни к чему. Зачем спрашивается на уровне клиента плодить бизнес-классы, если вся бизнес-логика лежит на СУБД и от клиента требуется ума только получить данные в виде набора данных, показать их для просмотра, организовать их отложенное изменение и потом пакетно сохранить все изменения ? Для организации такой работы в любой среде построения клиентов сейчас существуют стандартные компоненты доступа к данным, их визуального просмотра и построения отчетов. Этого вполне достаточно, чтобы организовать клиента в виде GUI приложения или интернет-проекта. В данном случае по моему личному мнению ООП будет использоваться по прямому его назначению - быстрой организации и легкой поддержки интерфейсной части. Всякие попытки перенести бизнес-обьекты на классы и потом танцевать с бубном по проведению их хранения и эффективности обработки на РСУБД только усложняют задачу. В конце концов при автоматизации какой то задачи у нас нигде в постановке нет задания создать аналог реального отображения обьектов. Нам всего то нужно обеспечечить хранение и обработку информации (именно информации, а не обьектов), где лучше всего подходят РСУБД и организовать удобный интерфейс работы с пользователем, где ООП очень полезна в плане создания повторно-наследуемых форм, компонент и других интерфейсных частей приложения. И тут, как только мы данные РСУБД начинаем рассматривать именно как информацию, а не понятно для чего нужные обьекты, все становиться на свои места. Плюс не понятно, что именно должно наследоваться в бизнес-обьектах - если какие то аттрибуты и логику сущностей можно выделить единым целым, то на "Один-ко-Многим" это все прекрасно реализуется по таблицам, триггерам, представлениям и хранимым процедурам по нормальным формам. Так что лично для меня понятия "Сущности-Аттрибуты" гораздо лучше ложаться на ТЗ поставленных задач, чем "Классы-Обьекты-Свойства". Единственный существенный недостаток, присущий кстати как РСУБД, так и ООП - это строгая формализация данных, где в обоих случаях поддержка обьектов с неизвестным заранее кол-вом аттрибутов будет стоить дополнительных усилий в проектировании и реализации эффективной работы. Опять же мое личное мнение - для этого необходимо вообще разделять данные и код бизнес-логики, причем данные должны быть структурами с произвольным набором аттрибутов определенных в словаре доменов, а бизнес-логика оперировать такими структурами с подходящими по наличию доменов и их значений (где опять же создаются расширяемые словари глаголов по принципам работы функциональных языков) и связывающим звеном для манипуляции множествами является язык запросов. В данном случае очень похоже на продвижение формата XML, хотя куда он двинется и что из этого получится пока не понятно :)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836048
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Роман Дынник

>Ничего она (Java) не мешается, Oracle-у уж точно :), а что касается Sybase дык писать нужно лучше чтоб под ногами java не мешалась.

Так никаких проблем, джава в сайбейзе есть, все замечательно, только использовать ее почему-то никто не хочет. Почему вдруг все дружно игнорируют джаву в SQL сервере?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836261
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
Ну во первых кто мешает вызывать просто sp_Ins5(@xml), передавая туда сразу все аттрибуты класса и его предков ? 
Мы же про передачу иерархического объекта заговорили в виде xml в сравнении с java-объектом.
Код: plaintext
Во вторых Вы пытаетесь на РСУБД наложить ООП, а при моем подходе это просто ни к чему. Зачем спрашивается на уровне клиента плодить бизнес-классы, если вся бизнес-логика лежит на СУБД и от клиента требуется ума только получить данные в виде набора данных, показать их для просмотра, организовать их отложенное изменение и потом пакетно сохранить все изменения ?
Сейчас многие так и поступают, именно на РСУБД накладывают ООП, и это правильно, иначе при огромном количестве сущностей поддержка проекта превращается в сущий ад в котором может разобраться только "основной" разработчик. Потом, у меня, например, как я уже говорил ВСЯ бизнес-логика на сервер не переносится. На сервер переносятся только CRUD операции в виде слоя хп. Что же касается бизнес-логики (далее БЛ) по части различных проверк на корректность ввода, в ряде случаев (не во всех) ветвлений if-ов - по моему мнению это дело именно среднего звена (если мы говорим о многозвенной арх-ре). При этом часть БЛ касающаяся проверки на корректность ввода дублируется и в среднем звене и на клиенте. И все это способствует масштабированию.
Код: plaintext
 Для организации такой работы в любой среде построения клиентов сейчас существуют стандартные компоненты доступа к данным, их визуального просмотра и построения отчетов. Этого вполне достаточно, чтобы организовать клиента в виде GUI приложения или интернет-проекта.
У меня стандартные компоненты доступа к данным используются для заполнения и просмотра списков и именно в этом их основное предназначение (если говорить о различных recordeset, dataset, reader-ах).

Код: plaintext
В данном случае по моему личному мнению ООП будет использоваться по прямому его назначению - быстрой организации и легкой поддержки интерфейсной части. Всякие попытки перенести бизнес-обьекты на классы и потом танцевать с бубном по проведению их хранения и эффективности обработки на РСУБД только усложняют задачу.
Странно, но мне как раз все это облегчает задачу.
Я знаю что вы являетесь поклонником продуктов Sybase...
Так вот, PD мне сильно облегчает жизнь в плане написания CRUD, и именно тем что при проектировании БД я использую ОО подход. Весь слой CRUD, а это порядка 70-80% всех хп в проекте генерируется VBSсript-ом на основании концептуальной модели данных, в соответствии с наследованием сущностей и их атрибутами.
В некоторых системах используются всякие Persistence/mapping компоненты, которые позволяют автоматически сохранять ОБЪЕКТ в БД (мапить его на sql-выражения) без особых услилий. Т.е. не нужно заботиться о создании слоя хп или прямых запросах. И эти компоненты давно ТАКЖЕ давно стали стандартными (JDO-java data object например). Лично я их не использую, именно потому что не нашел нигде маппинг на хп, но они, в ряде случаев, позволяют значительно сократить сроки разработки для небольших и средних проектов, а также используются в настраиваемых ERP-системах.
Код: plaintext
где ООП очень полезна в плане создания повторно-наследуемых форм, компонент и других интерфейсных частей приложения. 
ООП полезно везде. Пора перестать мыслить таблицами и полями.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836268
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторНу во первых кто мешает вызывать просто sp_Ins5(@xml), передавая туда сразу все аттрибуты класса и его предков ?
Мы же про передачу иерархического объекта заговорили в виде xml в сравнении с java-объектом.
авторВо вторых Вы пытаетесь на РСУБД наложить ООП, а при моем подходе это просто ни к чему. Зачем спрашивается на уровне клиента плодить бизнес-классы, если вся бизнес-логика лежит на СУБД и от клиента требуется ума только получить данные в виде набора данных, показать их для просмотра, организовать их отложенное изменение и потом пакетно сохранить все изменения ?
Сейчас многие так и поступают, именно на РСУБД накладывают ООП, и это правильно, иначе при огромном количестве сущностей поддержка проекта превращается в сущий ад в котором может разобраться только "основной" разработчик. Потом, у меня, например, как я уже говорил ВСЯ бизнес-логика на сервер не переносится. На сервер переносятся только CRUD операции в виде слоя хп. Что же касается бизнес-логики (далее БЛ) по части различных проверк на корректность ввода, в ряде случаев (не во всех) ветвлений if-ов - по моему мнению это дело именно среднего звена (если мы говорим о многозвенной арх-ре). При этом часть БЛ касающаяся проверки на корректность ввода дублируется и в среднем звене и на клиенте. И все это способствует масштабированию.
автор Для организации такой работы в любой среде построения клиентов сейчас существуют стандартные компоненты доступа к данным, их визуального просмотра и построения отчетов. Этого вполне достаточно, чтобы организовать клиента в виде GUI приложения или интернет-проекта.
У меня стандартные компоненты доступа к данным используются для заполнения и просмотра списков и именно в этом их основное предназначение (если говорить о различных recordeset, dataset, reader-ах).

авторВ данном случае по моему личному мнению ООП будет использоваться по прямому его назначению - быстрой организации и легкой поддержки интерфейсной части. Всякие попытки перенести бизнес-обьекты на классы и потом танцевать с бубном по проведению их хранения и эффективности обработки на РСУБД только усложняют задачу.
Странно, но мне как раз все это облегчает задачу.
Я знаю что вы являетесь поклонником продуктов Sybase...
Так вот, PD мне сильно облегчает жизнь в плане написания CRUD, и именно тем что при проектировании БД я использую ОО подход. Весь слой CRUD, а это порядка 70-80% всех хп в проекте генерируется VBSсript-ом на основании концептуальной модели данных, в соответствии с наследованием сущностей и их атрибутами.
В некоторых системах используются всякие Persistence/mapping компоненты, которые позволяют автоматически сохранять ОБЪЕКТ в БД (мапить его на sql-выражения) без особых услилий. Т.е. не нужно заботиться о создании слоя хп или прямых запросах. И эти компоненты давно ТАКЖЕ давно стали стандартными (JDO-java data object например). Лично я их не использую, именно потому что не нашел нигде маппинг на хп, но они, в ряде случаев, позволяют значительно сократить сроки разработки для небольших и средних проектов, а также используются в настраиваемых ERP-системах.
авторгде ООП очень полезна в плане создания повторно-наследуемых форм, компонент и других интерфейсных частей приложения.
ООП полезно везде. Пора перестать мыслить таблицами и полями.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836286
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>>>c127
Не используют потому что не привыкли, потому что мыслят таблицами и записями, потому что надо время на изучение а его нет, потому что не везде целесообразно применять java-процедуры.
Если признаться, раньше я и сам задавался вопросом где и зачем они мне могут понадобиться.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836340
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторООП полезно везде. Пора перестать мыслить таблицами и полями.
Да-да, и еще пора опять переносить бизнес-логику на клиента, делать в каждой системе обязательное среднее звено, доступ к БД может быть только через клиента или среднее звено......
А может все же облегчить себе жизнь?
Иногда нужно помыслить таблицами и полями - проще жить станет, намного проще.
А еще ООП не надо переносить на данные и вообще на все, что шевелится :) - это технология разработки и программирования приложения, но никак не технология манипулирования данными.

Вы расскажите смысл представления данных как объектов? Я вот не вижу. И гораздо проще иметь набор таблиц с полями, с которыми можно сделать что угодно, которые являются родными по отношению к СУБД - и следовательно проще и быстрее их обрабатывать и т.д.

В Оракле вот давно есть возможность создавать пользовательские типы данных, с методами, свойствами... Ну и что, много кто ее использует, эту возможность?

-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836353
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну и опять же легкость поддержки системы - если у вас логика зашита в клиента и вам нужно чего-то изменить, но не в выводе информации для клиента, а именно часть бизнес-логики, то вам придется каждый раз компилять клиента и выкладывать пользователям. В случае же бизнес-логики на сервере, ничего никуда ненадо выкладывать - все меняется для всех прозрачно. Вы еще не почувствовали разницу? Может вы просто не пробовали сделать обычное приложение с обычной РСУБД? Попробуйте.

Почему всегда забывают про поддержку (изменение, дополнение, исправление) системы??? Хотя это 70% работы. Но на это наплевать? Мда.

-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836389
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Дынник


Тем что делается несколько вызовов и как следствие - старт транзакции на стороне среднего звена/клиента вместо того что бы стартануть на сервере с последующими возможными проблемы с deadlock-ми.
Как вам (100+1) вызов на сохранение счета со 100 позициями?

С уровнями изоляции если правильно работать - то никаких deadlock'ов не будет
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836392
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И почему-то все рассматривается со стороны разработчика клиента : мне программировать так удобно, я знаю ООП и больше ничего знать нехочу, всякие там PL/SQL, TSQL учить и знать не хочу да и ваще мне пофиг все эти БД - я же универсальный программист, к СУБД никакого отношения не имею зато смогу сделать под любую БД, у меня же объекты!!!
Почему-то забывают про админа/архитектора/разработчика БД, который потом, когда жареный петух клюнет, каким-то образом должен будет разгребать завал, пытаясь поднять производительность, построить индексы, поменять чего еще, если вообще это можно сделать.
А забывают зря. Может потому что не знают, что сделать клиента - это 30% дела, а сделать так, чтобы это все работало, да еще без затыков, быстро и т.д. и т.п. - остальная работа.

-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836548
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторВы расскажите смысл представления данных как объектов? Я вот не вижу. И гораздо проще иметь набор таблиц с полями, с которыми можно сделать что угодно, которые являются родными по отношению к СУБД - и следовательно проще и быстрее их обрабатывать и т.д.

В Оракле вот давно есть возможность создавать пользовательские типы данных, с методами, свойствами... Ну и что, много кто ее использует, эту возможность?

А я и не говорил про создание пользовательских типов данных и ПОЛНОЙ реализации ООП в БД. Я наоборот против этого. Я говорил о способе мышления и как грамотно отразить классы на обычные таблицы с полями с привычними типами данных. Если отбросить среднее звено, клиента, и рассматривать одну лишь БД она НИЧЕМ не будет отличаться. Те же таблицы, типы данных, хп, вьюхи. Просто она будет более формализована, более прозрачна, ее модель будет более понимаема. Вообщем обычная база с таблицами в 3 НФ. Все что там присутствует от ООП - это всего лишь:
наследование в виде связи 1-1
методы в виде слоя хп
свойств и акцессоров get/set там нет и в помине, события... ну можно в первом приближении с большой натяжкой определить их как триггеры, но триггеры я вообще обычно не использую.

авторНу и опять же легкость поддержки системы - если у вас логика зашита в клиента и вам нужно чего-то изменить, но не в выводе информации для клиента, а именно часть бизнес-логики, то вам придется каждый раз компилять клиента и выкладывать пользователям. В случае же бизнес-логики на сервере, ничего никуда ненадо выкладывать - все меняется для всех прозрачно. Вы еще не почувствовали разницу? Может вы просто не пробовали сделать обычное приложение с обычной РСУБД? Попробуйте.
я почувствовал... когда в хп была зашита вся бизнес логика... начиная от проверки на допустимость ввода до выполнения cmdshell и вызовов COM. Сервак просто задыхался от выполнения таких процедур.
По поводу поодержки - разделяйте код на сборки, модули...
Про перенос БЛ на клиенте - я вообще к этому не призывал, я говорил что на клиенте должна ДУБЛИРОВАТЬСЯ проверка корректности ввода данных, это сокращает число повторных обращений к серверу (СУБД или к среднему звену или к веб серверу в случае если клиент - браузер, а проверка корректности ввода на JS).

>>tygra, вы вникайте повнимательнее в сообщения.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836633
andy st
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Роман Дынник
Сейчас многие так и поступают, именно на РСУБД накладывают ООП, и это правильно, иначе при огромном количестве сущностей поддержка проекта превращается в сущий ад в котором может разобраться только "основной" разработчик.

ООП также ничем не упрощает поддержку систем.
а вот что сильно упрощает - так это хорошо комментированные исходники и нормальная документация. а ООП или не ООП подход был при разработке системы - это вторичное и совсем не самое критичное.
какая разница, что переписывать при добавлении входного параметра в процедуру: саму процедуру и все вызовы к ней при обычном подходе или метод и все его вызовы при ООП?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836661
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Давайте разберемся по порядку. А то что-то я уже не понимаю ничего.
Давайте только без многозвенок. :)

Бизнес-логика. Так где же она? А то что-то в параллель топику про ООСУБД получилось ощущение, что вся БЛ на клиенте/среднем звене.
Лично у меня вся БЛ в СУБД, естественно за некоторым исключением или дополнением на клиенте в виде простейшего контроля ввода данных, типа ввели/неввели. Все, больше на клиенте ничего нет.

авторА я и не говорил про создание пользовательских типов данных и ПОЛНОЙ реализации ООП в БД. Я наоборот против этого.
Тут я тоже против.
авторЯ говорил о способе мышления и как грамотно отразить классы на обычные таблицы с полями с привычними типами данных.
Зачем???????????? Кто такие классы? Зачем они?
авторЕсли отбросить среднее звено, клиента, и рассматривать одну лишь БД она НИЧЕМ не будет отличаться. Те же таблицы, типы данных, хп, вьюхи. Просто она будет более формализована, более прозрачна, ее модель будет более понимаема.
Тогда смысл вашего ООП? Хотя как мне кажется, если в БД будут отражаться классы, то все-же не так будет понятно, как если бы структура была изначально сделана как обычно.
автор Вообщем обычная база с таблицами в 3 НФ. Все что там присутствует от ООП - это всего лишь:
наследование в виде связи 1-1
методы в виде слоя хп
свойств и акцессоров get/set там нет и в помине, события... ну можно в первом приближении с большой натяжкой определить их как триггеры, но триггеры я вообще обычно не использую.
Зачем вам ООП в данных, ну не понимаю я. Я не вижу смысла городить огород с ООП над данными. если у меня и так все есть и я все могу сделать с данными без проблем. Мне бы пример какой, показывающий разницу :)

авторя почувствовал... когда в хп была зашита вся бизнес логика... начиная от проверки на допустимость ввода до выполнения cmdshell и вызовов COM. Сервак просто задыхался от выполнения таких процедур.
Так с мозгами делать надо. И не пихать в СУБД то, чего там быть не должно. Можно и на клиенте все так сделать, что он и не запустится :))
авторПо поводу поодержки - разделяйте код на сборки, модули...
Какая разница? Все-равно если править в клиенте, то его придется копировать и перезапускать.
авторПро перенос БЛ на клиенте - я вообще к этому не призывал, я говорил что на клиенте должна ДУБЛИРОВАТЬСЯ проверка корректности ввода данных, это сокращает число повторных обращений к серверу (СУБД или к среднему звену или к веб серверу в случае если клиент - браузер, а проверка корректности ввода на JS).
Ну да, но проверка корректности ввода данных может означать разные вещи.

автор>>tygra, вы вникайте повнимательнее в сообщения.
Стараюсь. Сбивает мысли соседний топик про ООСУБД, елы-палы :))

======
И так. Пока что я никак не вижу смысла укладывать данные в ООП структуру.
Примеров пока не видел - поэтому больше ничего не могу сказать.

-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836679
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>>>Tygra's
Для примера, какие бы вы таблицы создали для простого
справочника клиентов с разделением на физические и юридические лица?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836696
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
to funikovyuri
авторТем что делается несколько вызовов и как следствие - старт транзакции на стороне среднего звена/клиента вместо того что бы стартануть на сервере с последующими возможными проблемы с deadlock-ми.
Как вам (100+1) вызов на сохранение счета со 100 позициями?
авторС уровнями изоляции если правильно работать - то никаких deadlock'ов не будет
Да? Даже если на 99 вызове внутри одной транзакции стартующей на клиенте/среднем звене неожиданно пропадет соединение с сервером БД?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836723
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Дынник

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

Да? Даже если на 99 вызове внутри одной транзакции стартующей на клиенте/среднем звене неожиданно пропадет соединение с сервером БД?
Да - DEADLOCK 'a не будет. Другой вопрос что приведенный вами пример относиться скорее не к вопросу выбора о том откуда управлять транзакциями (с клиента или с БД), а просто к типичной ошибке проектирования (решается с помощью всем известного патерна facade)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836727
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кстати, незакоммиченные данные на блокировочнике можно перехватить через грязное чтение, правда все никак не дойдут руки, чтоб выложить как это делается.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836752
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenman

далось, блин, это грязное чтение
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836785
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторДля примера, какие бы вы таблицы создали для простого
справочника клиентов с разделением на физические и юридические лица?
А прямо так, как у нас и сделано :)
Таблица Клиент, где все данные, относящиеся и туда и сюда: ФИО, мыло, дата, ... в общем, типа такого. И поле Юрлицо - если 0, значит нет, если 1 - значит это юрик, и тогда у него есть реквизиты =>
А это уже таблица Реквизиты, в которой есть ссылка на Клиента и все прибамбасы: счет, банк и т.д.
Вот вроде и все. Когда мне нужен просто клиент - селект фром Клиент. Если нужны реквизиты к тому же - left join Реквизиты. Ну и т.д.
Как вы можете прокомментировать?

авторРома, среди читающих этот топик, я среди тех кто полностью на вашей стороне. Просто думаю спорить об этом бесполезно (один тигра чего стоит :) )
Да, уж поспорить то я люблю :)). Но тут не спор ради спора - просто хочу узнать, чем лучше или чем хуже данная реализация.
Т.к. основные действия (да и почти все вообще) над данными производятся в БД, то какой смысл как-то специально менять их структуру для представления на клиенте?

авторкстати, незакоммиченные данные на блокировочнике можно перехватить через грязное чтение, правда все никак не дойдут руки, чтоб выложить как это делается.
"Выложу" для MS SQL, так и быть :)
Код: plaintext
select * from table with(nolock)

-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836919
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати, вспоминая про "весомые плюсы". Источник :

OTN : Can you tell us more about Oracle Developer Tools for Visual Studio .NET and Oracle Database Extensions for .NET?

Datta : Oracle joined the Microsoft Visual Studio Industry Partner (VSIP) program as a Premier Level Partner in May 2004 and we have been working very actively on developing Oracle Developer Tools for Visual Studio .NET. Oracle Developer Tools is a tightly integrated tool set within Visual Studio .NET to enable developers to use the power of the Oracle Database easily and effectively. With this tool set, Windows developers do not need to learn any new tool and can remain in Visual Studio environment throughout a project's lifecycle.

Oracle Developer Tools for Visual Studio .NET will support Oracle schema browsing and modification, wizards and designers, automatic code generation, an integrated help system, a PL/SQL editor, and many other features. A Beta release of the tool set will be available by the end of 2004. A production release is slated for the first quarter of 2005.

Oracle Database Extensions for .NET allow development and deployment of .NET based stored procedure in the Oracle Database. Stored procedures can be in VB.NET, C# or C++, and the deployment is supported from within Visual Studio environment. Stored procedures can use the server-side ODP.NET for interacting with the database. This release will be available in the first half of 2005.

OTN : What are the differentiators for Oracle in .NET environment?
"Oracle Application Server supports many features for integration with Windows and .NET."

Datta : Oracle Application Server supports many features for integration with Windows and .NET: I'll just go through a mental list, highlighting some features as I go.
The first that comes to mind is Windows Single Sign-On. Once a user is logged on to Windows, no further credentials are required. We also provide Active Directory integration, which extends user identity management through Oracle Internet Directory and the Oracle Identity Management infrastructure. Then there's Microsoft IIS support, where even though an application is developed for Oracle Application Server, it can still use Microsoft IIS as a Web server. We further extend integration through Oracle Portal, to aggregate Microsoft content, such as that from Exchange, and then wireless-enable it. Message exchange is also possible with Biztalk Server, ensuring business process integration.

Other integration has been done with Microsoft Cluster Services, providing high-availability for the Oracle Application Server infrastructure. We also offer interoperability with the use of Web Services, where interoperability with .NET applications and services are key features. Then there's WebDAV integration, which allows Windows desktop or Windows applications such as Explorer or Office to interoperate with those developed using Oracle Application Server.

Finally, we provide things such as Oracle Web Cache for improving the performance of ASP applications; a database adapter for SQL Server, where interoperability is enabled from Oracle Application Server to SQL Server; and Windows CE-based device support for mobile applications, where a broad range of Windows-compatible devices for individual and enterprise applications are enabled.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836930
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторТаблица Клиент, где все данные, относящиеся и туда и сюда: ФИО, мыло, дата, ... в общем, типа такого. И поле Юрлицо - если 0, значит нет, если 1 - значит это юрик, и тогда у него есть реквизиты =>
А это уже таблица Реквизиты, в которой есть ссылка на Клиента и все прибамбасы: счет, банк и т.д.
Вот вроде и все. Когда мне нужен просто клиент - селект фром Клиент. Если нужны реквизиты к тому же - left join Реквизиты. Ну и т.д.
Как вы можете прокомментировать?

Как же ФИО может относиться и к физ лицам и к юр?
И видимо ФИО хранится в одном поле и используется либо как наименование организации, либо как фамилия имя отчество для физ/лица?

А У нас так:
тбл. Контрагент (id,краткое наименование, инн)
тбл. Физ. лицо (id,Фамилия, Имя, Отчество ...)+fk к контрагенту по id (1-к-1 наследование)
тбл. Юридическое лицо/компания (id,Полное наименование, реквизит1, реквизит2 ...)+fk к контрагенту по id (1-к-1 наследование)

для вывода всех клинтов: select * from контрагент
для вывода всех юриков: select * from [Юридическое лицо] JOIN контрагент
для вывода всех физ.лиц: select * from [Физическое лицо] JOIN контрагент

видите, только из-за того что вы отвергаете мышление в терминах ООП вы сделали outer join, когда можно было join, что выполнится быстрее (незачем тащить реквизиты для физического лица). Это по мелочи. В принципе таблица реквизиты у вас тоже самое что и у меня юр/лицо и здесь тоже наследование (таблица Реквизиты, в которой есть ссылка на Клиента и все прибамбасы: счет, банк и т.д).
Но явно не выделена сущность "Физическое лицо" и в этом ошибка проектирования.

Теперь дальше...
Возникло новое требование.
Требуется создать справочник сотрудников, при чем сотрудник может быть клиентом.
Ваш действия?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836947
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
(Роман Дынник) >>
тбл. Контрагент (id,краткое наименование, инн)
тбл. Физ. лицо (id,Фамилия, Имя, Отчество ...)+fk к контрагенту по id (1-к-1 наследование)
тбл. Юридическое лицо/компания (id,Полное наименование, реквизит1, реквизит2 ...)+fk к контрагенту по id (1-к-1 наследование)
==

Всё-таки плохо, что можно завести контрагента, который будет ни физическим, ни юридическим лицом.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836950
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я бы сказал, что контагент - это обобщение понятия физических и юридических лиц. То есть, сначала надо заводить физическое или юридическое лицо. Потом делать ссылку в контрагенте на это лицо.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836965
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Дынник

В ER-нотации есть отношение generalization - так что при желании и знаниях решение будет в точности соответствовать предложенному
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836978
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
www.fun4me.narod.ruВсё-таки плохо, что можно завести контрагента, который будет ни физическим, ни юридическим лицом.
А кто сказал, что его можно завести? Для этого в Oracle Designer, например, существует специальное понятие "arc" - которое трансформируется в констрейнт примерно следующего вида

Код: plaintext
check ((a is not null and b is null) or (a is null and b is not null))

автор
А У нас так:
тбл. Контрагент (id,краткое наименование, инн)
тбл. Физ. лицо (id,Фамилия, Имя, Отчество ...)+fk к контрагенту по id (1-к-1 наследование)
тбл. Юридическое лицо/компания (id,Полное наименование, реквизит1, реквизит2 ...)+fk к контрагенту по id (1-к-1 наследование)

для вывода всех клинтов: select * from контрагент
для вывода всех юриков: select * from [Юридическое лицо] JOINконтрагент
для вывода всех физ.лиц: select * from [Физическое лицо] JOINконтрагент
Реальные структуры предъявляют еще большие требование - например, стоит помнить, что банки (в которых у контрагентов расчетные счета) имеют корр.счета в других банках, а сами банки при этом являются организациями и могут являться контрагентами. Впрочем, не понимаю, при чем здесь объектный подход - это вопрос грамотного или неграмотного проектирования в условиях той или иной конкретной задачи. ER-проектирование - достаточно "объектно".

Что еще хочется сказать по поводу сказанного Вами - в большинстве подобных задач запрос должен выглядеть как

Код: plaintext
1.
2.
select * from v$contractors
select * from v$phpersons
select * from v$organizations

То есть - постоянные join-ы стоит прятать во вьюхи (естественно, не забывая об эффективности). Во всяком случае, наличие в 50 различных запросах фразы "[Юридическое лицо] JOIN [контрагент]" меня серьезно насторожит.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836982
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторЯ бы сказал, что контагент - это обобщение понятия физических и юридических лиц
Именно это я и хотел сказать.
Код: plaintext
Всё-таки плохо, что можно завести контрагента, который будет ни физическим, ни юридическим лицом
Это уже бизнеслогика.
авторТо есть, сначала надо заводить физическое или юридическое лицо. Потом делать ссылку в контрагенте на это лицо.
Это как? т.е. в контрагенте у вас будет 2-а поля одно из которых ссылается на ф/л, другое на ю/л? Это не правильно.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836986
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Господа, только довайте не будем спорить по поводу контрагентов,физиков и юриков.Если есть желание подискутировать по этому поводу, то в ERP и учетных система есть огромный топик по этому вопросу. Вроде бы Oracle и MSSQL обсуждаем...
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32836995
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну таблица Контрагент тоже есть, я ее не привел чтобы упростить ответ.
А так - да, Контрагент ---> Клиент ---> Реквизиты

авторКак же ФИО может относиться и к физ лицам и к юр?
И видимо ФИО хранится в одном поле и используется либо как наименование организации, либо как фамилия имя отчество для физ/лица?
Ну что вы, как так можно? :) ФИО физлица для Юрика - это фио доверенного лица предприятия. А наименование организации лежит отдельно там где и положено - в реквизитах.

авторвидите, только из-за того что вы отвергаете мышление в терминах ООП вы сделали outer join, когда можно было join, что выполнится быстрее (незачем тащить реквизиты для физического лица). Это по мелочи.
При чем тут ООП? Я привел left join в качестве примера. Если мне нужны только физлица, то будет так:
Код: plaintext
select * from Client where Legal =  0 
Если юрики, то так:
Код: plaintext
select * from Client C join LegalData L on (L.ClientID = C.ID) where C.Legal =  1 
Та же скорость выполнения, так что нет никаких мелочей

авторВ принципе таблица реквизиты у вас тоже самое что и у меня юр/лицо и здесь тоже наследование (таблица Реквизиты, в которой есть ссылка на Клиента и все прибамбасы: счет, банк и т.д).
Но явно не выделена сущность "Физическое лицо" и в этом ошибка проектирования.
А тут мне кажется совсем наоборот - у вас есть ошибочка, тут я согласен с www.fun4me.narod.ru :)

авторТеперь дальше...
Возникло новое требование.
Требуется создать справочник сотрудников, при чем сотрудник может быть клиентом.
Ваш действия?
Ну, этак если дальше пойдет, мы систему тут напишем. Задаром
Это уже на усмотрение организации системы. Для чего нужен справочник сотрудников? Как и кто с ними будет работать. Можно заводить сотрудников отдельно, отдельно их как клиентов и связывать с клиентом, можно еще как-то, можно поставить отметку на клиенте о том, что он является сотрудником. Тут никак ООП не может влиять. Хотя вы все-же приведите, как бы сделали вы.
============
www.fun4me.narod.ruЯ бы сказал, что контагент - это обобщение понятия физических и юридических лиц. То есть, сначала надо заводить физическое или юридическое лицо. Потом делать ссылку в контрагенте на это лицо.
Или наоборот - при создании клиента сначала создается контрагент, а от него наследуется клиент. Тогда проще будет - хотя бы ID будут одинаковые.

-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837000
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторЧто еще хочется сказать по поводу сказанного Вами - в большинстве подобных задач запрос должен выглядеть как...
эти запросы во вью и завернуты. все так.

авторГоспода, только довайте не будем спорить по поводу контрагентов,физиков и юриков.Если есть желание подискутировать по этому поводу, то в ERP и учетных система есть огромный топик по этому вопросу. Вроде бы Oracle и MSSQL обсуждаем...
Давайте, а то оффтоп пошел сплошной.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837013
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerРеальные структуры предъявляют еще большие требование - например, стоит помнить, что банки (в которых у контрагентов расчетные счета) имеют корр.счета в других банках, а сами банки при этом являются организациями и могут являться контрагентами. Впрочем, не понимаю, при чем здесь объектный подход - это вопрос грамотного или неграмотного проектирования в условиях той или иной конкретной задачи . ER-проектирование - достаточно "объектно".
Полностью поддерживаю.

авторВо всяком случае, наличие в 50 различных запросах фразы "[Юридическое лицо] JOIN [контрагент]" меня серьезно насторожит.
Ну у меня физики и без вьюх - это одна таблица. А так - да, вьюхи нужны. Тока в MS SQL они странно работают, планы у них часто слетают. Может просто не знаю, как лечить, но пока что вьюхами особо не увлекаюсь.

Роман ДынникЭто как? т.е. в контрагенте у вас будет 2-а поля одно из которых ссылается на ф/л, другое на ю/л? Это не правильно.
Нет, это будет скорее всего, как я выше написал.

авторЭто уже бизнеслогика.
Правильно, это все бизнес-логика и архитектура БД. И никакого ООП.

ShtockГоспода, только довайте не будем спорить по поводу контрагентов,физиков и юриков.Если есть желание подискутировать по этому поводу, то в ERP и учетных система есть огромный топик по этому вопросу. Вроде бы Oracle и MSSQL обсуждаем...
Дык давно уж вопросы ушли вдаль от ответов. Или наоборот :)

-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837022
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Можно и отдельный топик. Но это уже будет 3-й топик с ООП БД

-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837036
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tygraНу у меня физики и без вьюх - это одна таблица. А так - да, вьюхи нужны.
В таких общих справочниках все равно оказывается куча мелочей - например, у физика есть документ, удостоверяющий личность, и типы этих документов, по идее - отдельный справочник.

tygraТока в MS SQL они странно работают, планы у них часто слетают. Может просто не знаю, как лечить, но пока что вьюхами особо не увлекаюсь.
Хм. Как-то так оказывается, что когда я на rsdn.ru цитирую местные утверждения про MS SQL - там просыпаются Sinclair или Merle и начинают говорить: "ну-ка, покажи, откуда ты это взял?" :)

А что, у вьюхи в MS SQL есть какой-то фиксированный план? Немного странная концепция, имхо...
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837051
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerА кто сказал, что его можно завести? Для этого в Oracle Designer, например, существует специальное понятие "arc" - которое трансформируется в констрейнт примерно следующего вида

check ((a is not null and b is null) or (a is null and b is not null))


автор

А У нас так:
тбл. Контрагент (id,краткое наименование, инн)
тбл. Физ. лицо (id,Фамилия, Имя, Отчество ...)+fk к контрагенту по id (1-к-1 наследование)
тбл. Юридическое лицо/компания (id,Полное наименование, реквизит1, реквизит2 ...)+fk к контрагенту по id (1-к-1 наследование)

для вывода всех клинтов: select * from контрагент
для вывода всех юриков: select * from [Юридическое лицо] JOINконтрагент
для вывода всех физ.лиц: select * from [Физическое лицо] JOINконтрагент


Я сказал, что в предложенной схеме:
[FIX]
тбл. Контрагент (id,краткое наименование, инн)
тбл. Физ. лицо (id,Фамилия, Имя, Отчество ...)+fk к контрагенту по id (1-к-1 наследование)
тбл. Юридическое лицо/компания (id,Полное наименование, реквизит1, реквизит2 ...)+fk к контрагенту по id (1-к-1 наследование)
[/FIX]
можно завести контагентов, не являющихся ни физическим, ни юридическим лицом, и никакой constraint вида check ((a is not null and b is null) or (a is null and b is not null)) никому это сделать не запретит, даже если он создан по понятиям "arc"

И я был прав!
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837063
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторХотя вы все-же приведите, как бы сделали вы.
тбл. сотрудник(id, должность)+fk к физ.лицо (1-к-1 наследование) по id

для создания сотрудника
1) insert в контрагент
2) insert в физ.лицо
3) insert в сотрудник
везде id будет один и тотже (1-к-1)
это что бы ясно было.
А реально бедет такая последовательность и вложенность вызовов:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
 
xsp_Ins_Employee(@id,@КраткоеНаименование,@ФИО,@должность)
     xsp_Ins_Person(@id,@КраткоеНаименование,@ФИО)
           xsp_Ins_Contragent(@id,@КраткоеНаименование)
              insert into contragent
           insert into Person
     insert into Employee
но все дело в том что я все эти xsp_Ins_xxx генерирую автоматом какая бы глубина наследования не была, поскольку они идентичны и хорошо формализованы, а в том получится ли это у вас, тигра, я не уверен...
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837159
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
www.fun4me.narod.ruИ я был прав!
Виноват - автоматом протянул ссылки в правильную сторону :)

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

Такие схемы, как правило, делают, одновременно разделяя по "все положительные - физики, все отрицательные - юрики)" или по другому аналогичному критерию. Но, с моей точки зрения, подобные игры со значениями ПК крайне нежелательны. Их можно оставить для каких-то системных вопросов, но частные прикладные решения лучше делать "как надо".
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837203
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторконтрагент будет и физ., и юр.лицом (поскольку соответствующие записи будут в обеих таблицах).
да не будет контрагент и физ и юр лицом одновременно никогда! либо физ, либо юр!
для физ будут записи: контрагент, физ
для юр будут записи: контрагент, юр
во вьюху физиков (физ JOIN контрагент) никогда не попадут записи из контрагент соответствующие юрикам.

во вьюху юриков (юр JOIN контрагент) никогда не попадут записи из контрагент соответствующие физикам.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837224
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Дынникда не будет контрагент и физ и юр лицом одновременно никогда! либо физ, либо юр!
для физ будут записи: контрагент, физ
для юр будут записи: контрагент, юр
За счет чего их не будет? За счет того, что Ваша программа (если Вы нигде не ошибетесь) сгенерит сначала id для контрагента, а потом использует его как id для физика либо юрика? К надежности этого.. я люблю вспоминать фразу Хайнлайна.

- Знаешь, как мы называем женщин, полагающихся на календарный метод? Матерями.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837249
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторЗа счет того, что Ваша программа (если Вы нигде не ошибетесь) сгенерит сначала id для контрагента, а потом использует его как id для физика либо юрика? К надежности этого.. я люблю вспоминать фразу Хайнлайна
Не ошибется, т.к. все операции ч/з манипулирования данными ч/з хп. прямые инсерты в таблицы не допускаются. Манипулирование данными - это часть бизнес-логики.

И с такими рассуждениями любую схему подвергнуть сомнению можно, что мешает ошибиться и поставить в поле-признаке юр/лица вместо "0" "1"?
Этак мы вообще далеко сейчас уйдем.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837343
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автортбл. сотрудник(id, должность)+fk к физ.лицо (1-к-1 наследование) по id

для создания сотрудника
1) insert в контрагент
2) insert в физ.лицо
3) insert в сотрудник
везде id будет один и тотже (1-к-1)
это что бы ясно было.
Ну это один из способов, о множестве которых я говорил. Да, и так можно.

авторно все дело в том что я все эти xsp_Ins_xxx генерирую автоматом какая бы глубина наследования не была, поскольку они идентичны и хорошо формализованы, а в том получится ли это у вас, тигра, я не уверен...
Вы не уверены, что я в состоянии написать N процедур для вставки во все таблицы? Ну...... Я был летом у шамана, так даже он мне такого не сказал. А вы, видать, покруче-то будете, раз на расстоянии (или через интернет) определяете мои способности :)). Нашел я более 1500 ХП, которые точно я написал (там есть опознавательные знаки). Пока что смог, надеюсь, что смогу и больше :)

авторХм. Как-то так оказывается, что когда я на rsdn.ru цитирую местные утверждения про MS SQL - там просыпаются Sinclair или Merle и начинают говорить: "ну-ка, покажи, откуда ты это взял?" :)

А что, у вьюхи в MS SQL есть какой-то фиксированный план? Немного странная концепция, имхо...
Ну не знаю лично, есть ли план у вьюхи, но то, что если в выборках использовать вьюху, и не одну, то очень часто бывает, что вдруг слетают планы у ХП и именно из-за вьюхи, да и вообще непредсказуемо поведение. Ну это на достаточно сложных вьюхах, больше 2-х таблиц с некоторыми параметрами. На простых вроде ничего.

-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837375
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ДынникНе ошибется, т.к. все операции ч/з манипулирования данными ч/з хп. прямые инсерты в таблицы не допускаются. Манипулирование данными - это часть бизнес-логики.
Тогда - готовьте пеленки :)

Роман ДынникИ с такими рассуждениями любую схему подвергнуть сомнению можно, что мешает ошибиться и поставить в поле-признаке юр/лица вместо "0" "1"?
А какой идиот будет вводить такой признак?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837417
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторА какой идиот будет вводить такой признак?
кое-кто вводит...

2Тигра
авторВы не уверены, что я в состоянии написать N процедур для вставки во все таблицы
Да уверен, уверен :)) просто я их не пишу, они у меня сами ГЕНЕРЯТСЯ (сами пишутся на основании ER-модели.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837436
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да я уж сам, по-старинке, руками :)) Тем более, что там есть еще кое-какая обработка, так что автоматически от силы 5% ХП можно сгенерить.

-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837440
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ДынникДа уверен, уверен :)) просто я их не пишу, они у меня сами ГЕНЕРЯТСЯ (сами пишутся на основании ER-модели.
2tygra (задумчиво): пофлеймить на тему "нахрена такие процедуры нужны"? Или пожалеть нервы читателей?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837441
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А кстати, softwarer то сам как эту "задачку" решит? С юриками-физиками

-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837452
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tygraА кстати, softwarer то сам как эту "задачку" решит? С юриками-физиками
Тогда уж постановку дайте :) А то основная причина флейма в таких темах - каждый говорит о задаче, которая у него когда-то была применительно к серверу, которым пользуется.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837460
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторДа я уж сам, по-старинке, руками :)) Тем более, что там есть еще кое-какая обработка, так что автоматически от силы 5% ХП можно сгенерить.
Ну вот... а у меня 70-80%
Вопрос подхода...

автор пофлеймить на тему "нахрена такие процедуры нужны"? Или пожалеть нервы читателей?
Пофлейми, пофлейми, раз делать нечего.
Все идут к тому чтобы сократить количество ручного коддинга, а ты еще флеймить собрался по поводу "надо или не надо".
Этак у нас бы сейчас ни case-средств не было ни UML, и на коленках бы рисовали.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837474
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ДынникПофлейми, пофлейми, раз делать нечего.
Все идут к тому чтобы сократить количество ручного коддинга, а ты еще флеймить собрался по поводу "надо или не надо".
Этак у нас бы сейчас ни case-средств не было ни UML, и на коленках бы рисовали.
Судя по этому заявлению, я верно оценил Ваш уровень.

hint: такая практика не сокращает количество ручного кодирования, а только добавляет кучу малоосмысленного автосгенеренного кода.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837485
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
сплошные оскарбления пошли, что за народ такой неуважительный...
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837496
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автосгенерированный код вполне осмысленный получается, вручную я написал бы тоже самое.

вот пример(сгенерировано все до запятой):

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
create procedure xsp_Ins_Person
(
@TicketSID		TSID,
@SID		            TSID        out,
@ID		                int         out,
@SysObjSysClSID		TSID ,
@SysObjSysFolderSID		TSID ,
@SysObjOwnerSID		TSID out,
@SysObjDTCreate		datetime out,
@SysObjDTLastChange		datetime out,
@SysObjUIDLastChange		TSID out,
@SysObjIsDel		TFlagYesNo ,
@SysFolderSysClSID		TSID ,
@SysFolderName		TUserName ,
@SysFolderisRootClFolder		TFlagYesNo ,
@SysFolderLFT		int ,
@SysFolderRGT		int ,
@ContragINN		TINN ,
@ContragNote		TNote ,
@PersFirstName		TUserName ,
@PersLastName		TUserName ,
@PersMiddleName		TUserName 
)
as
begin
BEGIN TRAN
exec xsp_mkSpHeader @TicketSID , @SysObjOwnerSID out, @SysObjSysClSID	out, 'Person', @@NESTLEVEL
if @@error<> 0  GOTO UNDO
exec xsp_Ins_Contragent
@TicketSID		,
@SID		out,
@ID		out,
@SysObjSysClSID		,
@SysObjSysFolderSID		,
@SysObjOwnerSID		out,
@SysObjDTCreate		out,
@SysObjDTLastChange		out,
@SysObjUIDLastChange		out,
@SysObjIsDel		,
@SysFolderSysClSID		,
@SysFolderName		,
@SysFolderisRootClFolder		,
@SysFolderLFT		,
@SysFolderRGT		,
@ContragINN		,
@ContragNote		


if @@error<> 0  GOTO UNDO
insert into Person 
(
SID,
ID,
PersFirstName,
PersLastName,
PersMiddleName
)
 values
(
@SID		,
@ID		,
@PersFirstName		,
@PersLastName		,
@PersMiddleName		
)
if @@error<> 0  GOTO UNDO
if @@TRANCOUNT> 0  COMMIT TRAN
return( 0 )
UNDO:
if @@TRANCOUNT> 0  ROLLBACK TRAN
end
go
И что тут мало осмысленного?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837506
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> И что тут мало осмысленного?

А почему процедура код ошибки не возвращает?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837526
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Проверка if @@error<>0 GOTO UNDO после вызова процедуры не гарантирует успешного её выполнения. Да и в остальном - осмысленности не много, но это моё личное мнение.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837555
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот пример для размышления:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
create procedure bad_generated_code
as
begin
    begin transaction
    select  1 / 0 
    rollback transaction
end
go
exec bad_generated_code
select @@error

Так что - срочно переписывайте весь свой автосгенерённый код
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837556
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор Да и в остальном - осмысленности не много, но это моё личное мнение.
я что то не пойму в чем смысл вашей осмысленности?
Если мне надо дополнительная бизнес-логика в процедуре я допишу ее.
я просто показал что не трачу время на рутиную работу связанной с созданием сигнатуры и хп и типичных действий выполняемых хп.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837564
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> я что то не пойму в чем смысл вашей осмысленности?

У Вас процедура неправильная. Только и всего.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837579
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
нда...
Что вы сцепились из-за физиков и юриков? Ступайте в Проектирование и разбирайте там способы решения конкретной задачи.

Без конкретной задачи не может быть и конкретного решения.

Кастельно темы.
Мне понравились вот такие новые фукнции в TSQL в Юконе.
RANK ()

DENSE_RANK ()

ROW_NUMBER ()

NTILE ()

Интересно например сравнить с аналогичными функциями в Оракле, сравнить насколько удачно или неудачно они реализованы.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837587
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
to www.fun4me.narod.ru


create procedure #bad_generated_code1
as
begin
begin transaction
select 1/0
if @@trancount>0 rollback transaction
end
go

create procedure #bad_generated_code2
as
begin
begin transaction
exec #bad_generated_code1
select @@error
if @@trancount>0 rollback transaction
end


exec #bad_generated_code2


-----------
266

(1 row(s) affected)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837606
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
/*-----------------------------

exec #bad_generated_code2

-----------------------------*/
Server: Msg 8134, Level 16, State 1, Procedure #bad_generated_code1____________________________________________________________________________________________________000002A8, Line 5
Divide by zero error encountered.
            
----------- 
0

(1 row(s) affected)

...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837617
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть такая поговорка, то что нового появляется в DB2 переходит в стандарт SQL.... Шутка...
RANK ()
DENSE_RANK ()
ROW_NUMBER ()
NTILE ()

По поводу этих функций все хорошо в меру.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837632
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerА что, у вьюхи в MS SQL есть какой-то фиксированный план? Немного странная концепция, имхо...Не верьте, при построении плана запроса, view раскрываются, если только план view жестко не зафиксирован хинтами.
tygraНу не знаю лично, есть ли план у вьюхи, но то, что если в выборках использовать вьюху, и не одну, то очень часто бывает, что вдруг слетают планы у ХП и именно из-за вьюхи, да и вообще непредсказуемо поведение. Ну это на достаточно сложных вьюхах, больше 2-х таблиц с некоторыми параметрами. На простых вроде ничего.Мне почему-то казалось, что Вы лучше разбираетесь в MS SQL. Как иногда говорят, с такими друзьями и врагов не надо :)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837634
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не, не будем флеймить! Тут по крайней мере!!!

Давайте все же новый топик создадим и там по поводу юриков/физиков и написания ХП разберемся.


-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837643
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Один мой знакомый, очень мной уважаемый человек из Sybase говорил, что когда он допрашивает нового кандидата на каку-нить вакансию у него первый вопрос - когда и в каких случаях Sybase пересматривает планы запросов у ХП.
Я не думаю что в этом плане MSSQL далеко ушел от своего родителя...
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837653
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторНе верьте, при построении плана запроса, view раскрываются, если только план view жестко не зафиксирован хинтами.
Я это понимаю, но факт есть факт, если сложная вьюха, то тормоза обеспечены.

авторМне почему-то казалось, что Вы лучше разбираетесь в MS SQL. Как иногда говорят, с такими друзьями и врагов не надо :)
На фиг враги - тут столько друзей :))
Я, если честно, во внутренностях выполнения запросов и т.д. не слишком то разбираюсь, так сказать в технической части. Но пока нет ни времени, ни охоты начинать - я не претендую на роль дба или гуру, просто есть некоторая часть опыта, позволяющая достаточно хорошо писать ХП. Остальное время уходит на разработку архитектуры (к счастью она не сильно зависит от знаний конкретной БД :)) + вообще много непрограммистской работы (не компьютерной, организационной так сказать). Но пока устраивает - меня не привлекает "маньячество" :) в программировании. Просто именно эта работа дает возможность зарабатывать деньги и ..... весело проводить время :))

-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837655
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторОдин мой знакомый, очень мной уважаемый человек из Sybase говорил, что когда он допрашивает нового кандидата на каку-нить вакансию у него первый вопрос - когда и в каких случаях Sybase пересматривает планы запросов у ХП.

А если бы еще знать, почему они слетают (на MS SQL), тогда вообще было прекрасно :))

-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837665
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 tygra
Каждый вопрос содержит часть ответа)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837669
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Роман Дынник.

Извиняюсь за оффтопик, но как вы получили ошибку 266 (Transaction count after EXECUTE indicates that a COMMIT or ROLLBACK TRANSACTION statement is missing. Previous count = %ld, current count = %ld.) - можете объяснить? А то я не могу это понять. Если бы вы поставили SET XACT ABORT ON, то вы бы получили именно в Вашем примере ошибку 8134, но в BOL про такое свойство SET XACT ABORT ON нигде ничего не написано. И в какой-то мере это недокументированное поведение.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837675
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Такое ощущение, что сегодня пятница.
Но календарь не врет - вторник, епрст... Хотя на улицу посмотришь, в монитор посмотришь - пятница блин, ну пятница......

А зря.....
А завтра вот у нас корпоративное празднование НГ. Правда я не иду - не люблю я этого :) И в следующую среду улечу к себе домой на НГ аж до 10 числа. Эээхххххххххххххх


-- Tygra's --
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837711
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ДынникИ что тут мало осмысленного?
Я бы спросил - что там осмысленного.

Малоосмысленного - то, что если Вам верно подсказывают насчет недостатков этого кода (я не знаю T-SQL и ничего не скажу по этому поводу), то Вам придется устроить массовую перегенерацию/redeploy половины Вашей базы.
В то время как достаточно было бы поменять пару строк в объекте типа "table inserter" (это, кстати, к объектному подходу). Если Ваша база уже стоит у клиента - Вам придется слать ему "патч" на десятки тысяч строк, в то время как достаточно бы было прислать одну dll-ку/class-файл.

Я в общем почти уверен, что Вы ответите. И почти уверен, что в дискуссии с Вами сумею защитить даже позицию "джависта-все-на-аппсерверщика", которую считаю в корне неверной.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837720
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
www.fun4me.narod.ru
я извиняюсь, правильнее будет возвращать ошибку через return.
пример некорректный был в плане управления транзакциями в #bad_generated_code1 и #bad_generated_code2.

придется подпатчить немного генератор и перегенерить десяток хп. Фу... а ведь иначе бы пришлось руками всё править...
SET XACT ABORT ON иногда много проблем решает.
==
оффтоп.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837724
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2nkulikov
а более точно можно? :)
в частности, причем тут "все хорошо в меру"?

PS. И потом, я привел всего лишь пример. В настоящий момент никакого отношения к Юкону беседа не имеет.
PPS. Для любителей ООП - в Юконе можно и объекты (UDT) сохранять. Вы бы поисследовали эту тему.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837737
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AAronИнтересно например сравнить с аналогичными функциями в Оракле, сравнить насколько удачно или неудачно они реализованы.
Хм. А как Вы представляете себе сравнение того, что реализовано в Оракле, с тем, что будет реализовано в (непонятно когда) выходящем Yukon. Или я отстал от жизни и он уже вышел?
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837747
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerИли я отстал от жизни и он уже вышел?Yukon AKA MS SQL 2005... По календарю 2004 :)

P.S. Вторую бету мучают.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837795
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Дынник
Судя по Вашим высказываниям я вывел для себя примерно такую мысль "Мне с Тигрой давно пора бросать проектировать таблички и ХП, и переходить на ООП, потому что Вам так удобнее". Не обижайтесь, но смысл полностью таков.

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

Далее могу сказать, что у меня на WatcomSQL (диалект ХП для ASA) написан движок, который по макетам может генерить ХП с параметрами, при запуске которых они создают в БД ХП, генерящие нужные действия. Это используется для генерации в моих личных целях HTTP-контентов и организации интранет-сайтов на базе ASA. Это же используется для генерации по макетам хранимых процедур и триггеров. Движок этот занимает ровно 12 небольших по обьему хранимых процедурок, которые расковыривают макет, выщемляют с него тело, определяют секции и параметры, описанные на XML, преобразуют ключевые слова в действия и генерят все в виде WatcomSQL скриптов. В итоге в моих БД 80% ХП тоже генериться автоматически. Я мог написать такой движок на ООП, но уверяю, меньше бы по размеру и трудоемкости написания он не стал, просто бы пришлось использовать при написании другие парадигмы.

Далее мои и Ваши 80% автоматически сгенерированных процедур в БД не говорят о том, что мы с Вами круты, а вот Тигра нет. Это говорит только о том, что мы с Вами предпочитаем уводить DML операторы на уровень хранимых процедур и они вполне однотипны согласно определенным макетам. У меня во всяком случае в зависимости от типа сущности, который может обьединять в себя множество связанных таблиц и определенные аттрибуты могут автоматически генерится множество процедур по 7 различным макетам, все назначение которых - свести работу клиентского приложения с базой данных до примитивного уровня - получил в простом виде, изменил и вызвав ХП зафиксировал изменения в простом виде. Я уже молчу про множество автоматом генерящихся триггеров, которые в зависимости от определенной модели поведения занимаются различными проверками, вычислениями и другой полезной, но в принципе рутинной работой.

Что имеем в заключение ? Имеем, что не средство определяет специалиста, а специалист определяет средство. Так же имеем, что чем шире у специалиста кругозор, тем больше решений в различных измерениях он может осознать и применить. Не надо думать, что Тигра или я в жизни не занимались ООП. Лично я потратил на это 7 лет своей жизни, написал добрую сотню визуальных/невизуальных компонент, несчетное кол-во классов, с десяток интрепретаторов и различных парсеров. Поэтому не надо лично мне заявлять, что мне пора отвыкать от таблиц и полей - это на самом деле не серьезно. Я знаю что такое ООП и успешно использую его по назначению каждый божий день :)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32837800
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гы - не удержусь - в конце концов с ООП я знаком с 1990 года, когда мне в руки попал славный добрый Turbo Pascal 5.5 и первое что я на нем сделал в качестве осмысливания ООП - это собственную навигационную базу данных :) Странно, что я с тех пор переменил свое мировозрение, не правда ли ? :)
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32838013
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Роман Дынник

>Не используют потому что не привыкли, потому что мыслят таблицами и записями, потому что надо время на изучение а его нет, потому что не везде целесообразно применять java-процедуры.

Времени на изучение было больше 10 лет, это не объяснение. Когда в сайбейзе вводили поддержку джавы, очень многие сторонники ООП-а радостно потирали руки. Их-то учить не нужно. Но получился пшик, джава не прижилась, все продолжают использовать WatcomSQL. Думаю с другими SQL серверами та же ситуация.

Есть более простое и правдоподобное объяснение: джаву в SQL серверах не используют потому что не удобно. Записи, поля, отношения гораздо удобнее объектов. ИМХО. По крайней мере для меня это так, теперь подтверждают и другие тоже.

Я сам использую ООП иногда, в тех случаях, когда он что-то экономит, но экономит он далеко не всегда.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32838954
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2softwarer
Вообще, есть бетты, есть Express2005. Постоянно проводятся разные семинары.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32839505
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
учитывая мой жестко критикуемый опыт в написании серверной логики, прошу
здесь обсудить шаблон для вложенных хп.
...
Рейтинг: 0 / 0
Весомый плюс Юкон над ORACLE
    #32839828
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AAron2softwarer
Вообще, есть бетты, есть Express2005. Постоянно проводятся разные семинары.
Хм. Боюсь, я не представляю, как в таких условиях сравнивать реализацию. Насколько я понимаю, можно заявить, что "видимо, такие функции будут"; можно сказать, что "видимо, позволят меньше" либо "похоже, могут позволить и больше". Но собственно ключевые параметры работы - скорость и потребные ресурсы - сравнивать можно только у релизов.
...
Рейтинг: 0 / 0
200 сообщений из 200, показаны все 8 страниц
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Весомый плюс Юкон над ORACLE
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]