Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
В Юкон будет реализована возможность программировать триггеры, ХП, 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2004, 16:10 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Привет, 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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2004, 16:51 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Имхо если язык (SQL) создан специально для какой либо узкой задачи то, вероятно, он превосходит другие языки (применительно к решению этих задачь) для решения более широких задачь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2004, 18:03 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
В Оракле 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 под ногами для дальнейшего развития этой СУБД. Лично я с ними полностью согласен, думаю для СУБД главное надежность и скорость работы, а при вводе любой сторонней платформы эти параметры здорово снижаются (тем более когда это виртуальные машины со сборщиками мусора). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2004, 19:15 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
StalkerSВ Юкон будет реализована возможность программировать триггеры, ХП, UDF с помощью любого .NET совместимого языка (такого как Visual Basic® .NET и C#). Мне кажется это весомым плюсом в сравнении с ORACLE, где есть поддержка только Java. Ну дак когда будет реализована, тогда и обсудим. А то у меня тут идей - так вообще прорва! Ух, как размахнусь, К-А-А-К напишу! Кстати, сколько глюков там запланировано? M$ VisualStudio работать-то будет, или как в XP, после 3-го SP. MSVS попал в список несовместимых с XP продуктов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2004, 19:27 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
>> M$ VisualStudio работать-то будет, или как в XP, после 3-го SP. MSVS попал в список несовместимых с XP продуктов?или как в XP, после 3-го SP. MSVS попал в список несовместимых с XP продуктов? У меня после установки 3-го SP все прекрасно продолжает работать, в том числе и M$ VisualStudio.... Может у меня с руками что-то не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2004, 19:39 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2:www.fun4me.narod.ru Опечатался, SP2 А вообще почитай тут: http://www.compulenta.ru/2004/12/2/52343/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2004, 19:53 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
.NET - это платформа на которую microsoft сделала ставку, они вбухивают в нее огромные деньги, так что полная интеграция MSSQL и .NET открывает большие возможности. Я, например, не вижу ничего плохого в том, что можно будет пользоваться огромной библиотекой классов, и вообще всеми достоинствами полнофункциональных языков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2004, 20:10 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Плохо будет, если они на старый добрый SQL болт забъют. Вопрос: какие функции, необходимые при работе с БД НЕ реализованны в анси 92? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2004, 20:30 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Еще, наверное, интересно это прочитать: http://www.compulenta.ru/2004/11/29/52207/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2004, 20:31 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
лет через 5 должна победить одна из моделей - или субд будет лишь хранилищем для апп-сервера или апп-сервер сольется в экстазе с субд. поэтому - что java что .Net это пока закидывание удочек. java в оракле (которая в субд) не используют для написания бизнес логики, это то что иногда применяют когда это на pl/sql реализовать слишком сложно, и бывает, что очень выручает. T-SQL гораздо беднее, и подобная выручалочка просто необходимость. Java и .Net врядли в ближаейшее время по производительности приблизятся к T-SQL/PLSQL поэтому имхо перспективней какойнибудь php/sql или perl в posgres. там и ооп и конструкции языка на 5 лет впереди ... жаль херово работает :) ЗЫ. а IBM похоже засунет .Net в db2 раньше ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2004, 20:35 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
StalkerSВ Юкон будет реализована возможность программировать триггеры, ХП, UDF с помощью любого .NET совместимого языка (такого как Visual Basic® .NET и C#). Мне кажется это весомым плюсом в сравнении с ORACLE, где есть поддержка только Java. 1) А как обеспечить переносимостью такого кода на UNIX? 2) Что с производительностью по сравнению с родным языком ХП? 2) Зачем вообще перегружать СУБД бизнес-логикой? Для этого серверы приложений придумали, да и еще J2EE и .NET. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2004, 22:59 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2 Андрей Прохоров 1) А как обеспечить переносимостью такого кода на UNIX? Вобщето MS SQL под UNIX делать пока не планируется. Но вот .Net там вполне может быть и тут с переносимостью проблем не возникнет - на то она и .Net чтоб ни от чего не зависеть. 2) Что с производительностью по сравнению с родным языком ХП? Родной язык всё равно останется 2) Зачем вообще перегружать СУБД бизнес-логикой? Для этого серверы приложений придумали, да и еще J2EE и .NET. А зачем иметь два сервера, когда можно обойтись одним? А вообще трудно не согласиться с ASCRUSом - лучше бы они T-SQL-ю больше внимания обращали, плюс совсем невесомый получается ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2004, 00:57 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
а почему все так уверены, что в 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2004, 09:54 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
SergSuper1) Вобщето MS SQL под UNIX делать пока не планируется. Но вот .Net там вполне может быть и тут с переносимостью проблем не возникнет - на то она и .Net чтоб ни от чего не зависеть. Для Oracle переносимость ХП и триггеров принципиальна. SergSuper2) Родной язык всё равно останется Это понятно, вопрос в производительности кода на .NET по сравнению с Transact SQL. SergSuper2) А зачем иметь два сервера, когда можно обойтись одним? Тогда зачем вообще .NET нужен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2004, 12:44 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
А теперь вернемся к самому топику: - Весомый плюс Юкон над ORACLE - более правильно: Весомый плюс ORACLE над Юкон - это то, что Oracle - уже есть, а Юкона - еще нет. Дык что с чем сравнивать-то? Как можно оценивать то, что есть, с тем чего нет? NULL можно сравнить только c NULL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2004, 15:39 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
null нельзя сравнивать даже с null ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 02:08 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
StalkerSМне кажется это весомым плюсом в сравнении с ORACLE, где есть поддержка только Java. Поскольку это утверждение - неверно само по себе, сравнение, мягко говоря, малоосмысленно. Вернее, сравнение в пользу Oracle, в котором можно писать и не на .NET-языках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 13:54 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
странно что по поводу .Net такая эйфория. IBM DB2 уже реализовала эту возможность в версии 8.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 14:13 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
StalkerSВ Юкон будет реализована возможность программировать триггеры, ХП, UDF с помощью любого .NET совместимого языка (такого как Visual Basic® .NET и C#). Ключевые для понимания слова выделены жирным. Когда они перейдут в настоящее время - будем разговаривать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 14:13 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
MasterZiv Когда они перейдут в настоящее время - будем разговаривать. Тогда может будет уже поздно. Нужно сейчас уже что-то предпринмать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 19:23 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Привет, vadiminfo! Ты пишешь: vadiminfo MasterZivКогда они перейдут в настоящее время - будем разговаривать. Тогда может будет уже поздно. Нужно сейчас уже что-то предпринмать. Предлагаю предпринять поход в кабак! Пиво - вот достойный ответ проискам сил мирового империализЪма! -- With best regards, Мимопроходящий. Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 19:34 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Мимопроходящий vadiminfo MasterZivКогда они перейдут в настоящее время - будем разговаривать. Тогда может будет уже поздно. Нужно сейчас уже что-то предпринмать. Предлагаю предпринять поход в кабак! Пиво - вот достойный ответ проискам сил мирового империализЪма! Поддерживаю!!! То, что осталось на плаву, т.е. не утонуло в Пиве - продукт стоящий! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 19:46 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Не доконца мысль излил... Ударим Пивом по M$-рожью и разгильдяйству !!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 19:49 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2 gardenman >странно что по поводу .Net такая эйфория. IBM DB2 уже реализовала эту возможность в версии 8.2 Так вот оно же и есть самое главное: не важно что, где и как реализовано, важно чтоб эйфория была. Бабки-то платят те, кто в эту эйфорию втянут прямо или косвенно. А они, зеленые, и есть конечная и единственная цель. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2004, 02:18 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Давайте разберемся по пунктам 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 . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 15:50 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
segunДавайте разберемся по пунктам 1. gardenmanстранно что по поводу .Net такая эйфория. IBM DB2 уже реализовала эту возможность в версии 8.2что значит уже реализоваЛА? В статье Сможет ли Stinger затмить Yukon? есть фраза: "Во всех статьях рассказывалось о предстоящем выпуске DB2 UDB 8.2 (условное название Stinger) осенью 2005 г. ". Или я что-то пропустил? DB2 v8.2 находится в продаже с сентября этого года. Если есть желание, можете взять триальную версию с сайта ИБМ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 16:28 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Наверное это опечатка... Кстати Oracle после выхода Stinger сделал анонс что тоже реализует такую функциональность правда когда не сказал... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 16:32 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
а MS триггера before так и не собираются делать?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 16:32 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
на счет .Net: http://www-128.ibm.com/developerworks/db2/library/techarticle/0304alazzawe/0304alazzawe.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 16:38 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
gardenmanа MS триггера before так и не собираются делать?.. ИМХО, необходимость в BEFORE-триггере вполне перекрывается INSTEAD-триггерами. По крайней мере, я не смог придумать ситуацию, в которой BEFORE-триггер оказался бы существенно более полезным, нежели INSTEAD. Пусть меня поправят, если я не прав. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 17:39 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
странно, в других базах ORACLE,DB2 нашлось место и тем и другим... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 17:45 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
а триггеры на уровне строки тоже не нужны?... печально... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 17:47 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
здорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 17:47 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
segunздорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before Хм. Я затруднюсь придумать ситуацию, в которой нельзя обойтись вообще без триггеров. Но это не повод их не делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 17:51 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
gardenmanстранно, в других базах ORACLE,DB2 нашлось место и тем и другим...я нашел пример, но врядли он вам понравится. это облегчение миграции с СУБД, в которых он реализован. На самом деле я не противник дополнительной функциональности, больше фич хороших и разных! Но так как MS постоянно проводит различные исследования на предмет как именно используются ее продукты в компаниях, какие у заказчиков есть пожелания к следующим версиям продуктов, их функциональности, простоты использования и т.д., и, с учетом этого, до сих пор нет триггеров before - это означает лишь одно. Пока есть более приоритетные вещи, чем эта разновидность триггеров. Значит они не так нужны при разработке решений на SQL Server, либо хорошо заменяются триггерами instead. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 18:09 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторНо так как MS постоянно проводит различные исследования на предмет как именно используются ее продукты в компаниях, какие у заказчиков есть пожелания к следующим версиям продуктов, их функциональности, простоты использования и т.д.... И вы думаете, что им важны ваши пожелания... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 18:49 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
segunздорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before Ну например, вместо удаления записи, она переносится в архив. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 19:15 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Рыжий Кот И вы думаете, что им важны ваши пожелания... :) да. очень. и я не думаю, я знаю. или думаю что знаю. :) не хочу никого лечить, но, на мой взгляд, на сегодняшний день это одна из самых открытых компаний-разработчиков ПО. Кстати, если кто не знает, есть интересный сайт о том как создаются продукты в MS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 19:19 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
nik_x segunздорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера beforeНу например, вместо удаления записи, она переносится в архив.как переносится, физически? то есть в другую таблицу или секцию, если мы говорим о секционированной таблице? Или удаление подразумевает просто обновление статуса записи? Напишите немного подробнее пожалуйста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2004, 19:27 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
nik_x segunздорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before Ну например, вместо удаления записи, она переносится в архив. Для этого случая и after пойдёт. А если имелось ввиду что запись на самом деле не удаляется, а только ставится какой-то флаг - то тут как раз instead. Чтобы из instead сделать before надо только одну строчку дописать, неужели это может быть так принципмально? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 00:47 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
SergSuper nik_x segunздорово бы помог конкретный пример ситуации, когда ну никак не обойтись без триггера before Ну например, вместо удаления записи, она переносится в архив. Для этого случая и after пойдёт. А если имелось ввиду что запись на самом деле не удаляется, а только ставится какой-то флаг - то тут как раз instead. Чтобы из instead сделать before надо только одну строчку дописать, неужели это может быть так принципмально? Уважаемый SegrSuper. У вас есть хорошая возможность меня убедить в том, что триггеры INSTEAD действительно могут заменить триггеры BEFORE. Задача: имеется 2 таблицы 1) Проводки (id проводки,счет, сумма, дата) 2) Журнал_ движения (счет, дата, сумма оборотов за день) реализовать: 1) При добавлении записи в журнал движения по счету сумма оборотов за день формируется как select sum(сумма) from Проводки where Проводки.счет= Журнал_движения.счет и Проводки.дата=Журнал_движения.дата 2) при добавлении в таблицу Проводок записи, если уже сформирован журнал движения, то возвращается ошибка. 3) если существует журнал движения за конкретную дату, то нельзя удалить запись в таблице проводок за эту дату, т.е. сначала должен быть удален журнал проводок. Реализовать всю схему без использования ХП,исключительно на триггерах ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 10:42 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2 gardenman А зачем тут before триггеры? Во всяком случае у меня несколько более сложная схема проводок (наверняка и Вы тут упростили свою задачу) и всё на триггерах after. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 10:58 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Да, я упростил до невозможности. первый триггер Before должен проинициализировать сумму в таблице движения до вставки записи. второй триггер before должен возвратить ошибку до вставки в таблицу проводок ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 11:10 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
и еще вопросик, сколько тригеров INSTEAD OF INSERT одновременно может висеть на одной таблице? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 11:13 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
ИМХО практика доказала, что все в одном (Сервак приложений и СУБД) рассчитано на универсальность, что означает потерю производительности. Моя мнение такое должна быть СУБД с SQL и отдельный Application Server. Ведь это распределнная логика, которая быстрее по своей сути. Вот пример: Есть СУБД и несколько клиентских программ. Скажем так одни клиентские приложения используют простые запросы для получения текущей информации, а другие клиенты используют сложные запросы + доп возможности .NET и т.п. При распределении простые приложения будут общаться напрямую с СУБД, а сложные через сервер приложений. Если же будет все в одном, то и те и другие будут задействовать и СУБД и сервер приложений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 12:04 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
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 есть куда стремиться? На мой взгляд, это нормальное развитие ситуации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 12:08 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
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 системы. А если уязвима ОС, то вы на нее хоть черта ставьте - не поможет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 12:18 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
мда .. меняем mssql на mysql а оракл на mssql и понимаем какую чушь пороли :) -------- 99.99% всех задач, реализованных на mssql или другой RDBMS можно сделать на mysql без особых проблем, думаю вы с этим не будете сильно спорить. Обратное, несомненно, тоже верно. (0.01% я не указал на всякий случай, не более того). Неужели вы думаете, что такая простая задача не реализуема с помощью mysql ? Методы решения могут отличаться, но заказчик отличий не увидит. Данная задача решается с помощью выноса логики на апп-сервер.Неясно, по какой причине вы сразу отклонили использование апп-сервера, ну да ладно. Главное - что она решается. И без каких-либо потерь в производительности. Давайте все-таки не будем проверять функциональную пригодность mysql. Я же вас не спрашиваю, почему уязвимостей в безопасности mssql больше чем в mysql. -------- ЗЫ. mssql это пока единственная субд добившееся действительно впечатляющих результатов в области секурити - это единственая субд с вирусами на пару дней вывела из строя целый регион. такое еще никому не удавалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 12:24 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Приведите, пожалуйста, ссылки на независимые компании в которых были проведены эти исследования. Например, за 2003-2004 годы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 12:24 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2 Yo!: глупо отрицать успехи конкурентов, и в частности mySQL. Все-таки почему так тянет пособачиться? Экскрементов на вентилятор любой СУБД можно бросить предостаточно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 12:29 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
мне просто хотелось показать как глупо выглядело вашу утверждение о 99% :) думаю мне это удалось ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 12:35 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Реально разработчику БД приходится знать кроме классического SQL, фирменные навороты в виде PL/SQL или T-SQL, не считая языка разработки "морды". Логично перевести логику, обработку ошибок, строковые и другие ф-ции на язык разработки. Старая идея в новом воплощении от MS. У ORACLE оказалась не очень востребована интеграция с java. Посмотрим, что будет у MS. Пока многообещающе звучит. Опять же, MS обычно начинает позже других, гармотно учитывает чужие ошибки и потом зачастую выигрывает ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 12:38 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2 sergun Вы правы, систему можно реализовать несколькими сособами. Про эффективность говорить не будем. Почему я сразу отклонил использование ХП? я постараюсь ответить. Все это конечно ИМХО. Когда я создаю модель, то стораюсь сделать ее как можно более надежной дуракозащищенной , не только от пользователей, но и от своих собственных ошибок и ошибок других программистов. Чтоб другой программист, каким бы ломом или кувалдой не бил по моей модели, т.е. какие бы кривые ХП не писал, данные всегда бы оставались согласованными. Совокупность триггеров BEFORE/AFTER/INSTEAD, UNIQUE INDEX, PRIMARY&FOREIGN KEY, CHECK CONSTRAINT - как раз и позволяют это сделать. Что касается ХП...)) То эту задачу на них складывать не люблю. Я считаю ХП - прикладным уровнем и не дело ХП следить за согласованностью данных. Во всех системах этих ХП столько, что в каждой из них упомнить что и как сосгласовывается - очень трудно. Перенося проверку согласованности на ХП (а проверять согласованность так или иначе все равно когда-нить да придется) вы загромождаете код ХП. использование триггеров позволяет делать системы более модульными, понятными. Можете со мной не соглашаться. Я просто люблю экономить свое время, и не переписывать одно и то же по нескольку раз. Конечно это все субъективно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 12:47 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2Yo!: молодой человек, вам удалось только показать свое воспитание и нетерпимость к инакомыслию. 2Leonid: ну да, звучит многообещающе, тем более, как я упоминал выше, если .Net в БД не будет нужен - его можно будет и не включать. То же самое касается и некоторых других частей продукта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 12:52 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2 gardenman первый триггер Before должен проинициализировать сумму в таблице движения до вставки записи. из условий это никак не вытекает. Какая разница сначала просчитать или потом? Проводки то за это время не меняются. второй триггер before должен возвратить ошибку до вставки в таблицу проводок во-первых если произошла ошибка и делается роллбэк - то не важно была вставка или нет, во вторых это можно сделать констрейтами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 13:01 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Еще хорошо, что ".NET логика" в Yukon будет по умолчанию компилироваться в nativ код и будет выполняться явно быстрее чем T-SQL логика. Народ уже проверял на MSSQL Server 2005 Express Beta2 - реально быстро. У ORACLE PL/SQL тоже можно откомпилировать в nativ код, но несколько геморойнее. А вот java у него явно тормознутая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 13:06 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
>молодой человек, вам удалось только показать свое воспитание и нетерпимость к инакомыслию. да вот такие мы иные :) (sybase, db2 и oracle ) со своими ненужными тригерами, и иным версионым механизмом (snapshot) и джавой (.Net), iFs (WinFs) и другими не нужными вещами еще незапланированых в Юконе ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 13:27 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2gardenman: вы будете удивлены, но я согласен с вашим постингом от 12:47 :) тем не менее, можно на SQLServer сделать это только на триггерах, можно. Если не все (оговариваюсь опять же на всякий случай), то особо важную часть. Триггеры + udf-функции. Я с SQLServer работаю больше 5 лет и делал проекты в разных областях: банки, аналитические приложения, интернет/интранет сайты. Поверьте, опыт большой. Но я нигде не перекладывал все логику работы с данными только на триггеры. Возможно это именно из-за особенностей SQLServer. Возможно на Oracle я бы делал все на триггерах :). Однако, есть задачи в которых защита от дурака чувствительно влияет на производительность, поэтому, не всегда она имеет смысл в полном объеме на уровне схемы. Все это, разумеется, ИМХО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 13:27 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Вот не понимаю я, какой такой там код в ХП нужен, что так скорость выполнения его критична. У меня в ХП в основном DML команды, все остальное только их связывает. Если что то и реально может тормозить, так это запросы, поэтому надо думать разработчики СУБД не просто так нянчяться с оптимизатороми запросов и постоянно их совершенствуют. Ну а если уж реально какой то код расчета чего то не имеющего прямого отношения к БД хочется делать, так Си никто не отменял, пишите внешние функции, подключайте, наслаждайтесь скоростью. Или выносите на 3-е звено, если бизнес-логика сложная, тут до фени - C#, Java, Delphi, PowerBuilder, и т.д. Не надо СУБД превращать в помойку, а то так докатимся, что через n-лет выйдет DOOM 4 на базе MSSQL. Поэтому я и считаю .NET в MSSQL просто маркетинговой фишкой - нормальные разработчики БД не рискнут на сервере поднимать виртуальную .NET машину, отдавая в обмен ресурсы, скорость и надежность и вполне оправданно будут бурчать, что лучше бы TSQL расширили, избавились от многих "исторически сложилось" и разного геммора, который конечно же можно обойти, но затратив дополнительные усилия, а то и вообще сначала дойдя до белого каления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 13:28 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
ASCRUSУ меня в ХП в основном DML команды, все остальное только их связывает. Если что то и реально может тормозить, так это запросы, поэтому надо думать разработчики СУБД не просто так нянчяться с оптимизатороми запросов и постоянно их совершенствуют. Ну с этим, слава богу, у MS вроде все впорядке. ASCRUSНу а если уж реально какой то код расчета чего то не имеющего прямого отношения к БД хочется делать, так Си никто не отменял, пишите внешние функции, подключайте, наслаждайтесь скоростью. Или выносите на 3-е звено, если бизнес-логика сложная, тут до фени - C#, Java, Delphi, PowerBuilder, и т.д Да все можно и сейчас. Кто спорит-то? Хочется удобнее и проще. ASCRUSНе надо СУБД превращать в помойку, а то так докатимся, что через n-лет выйдет DOOM 4 на базе MSSQL. Так это ж круто! Можно будет: SELECT секретки FROM уровень WHERE бонус >= "до хрена" Если серьезно, то почему же в помойку. Никто не отменит SQL и грамотное построение запросов, но то "что их связывает" пока оставляет желать лучшего и к то му же очень специфично от сервера к серверу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 13:49 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
LeonidЕсли серьезно, то почему же в помойку. Никто не отменит SQL и грамотное построение запросов, но то "что их связывает" пока оставляет желать лучшего и к то му же очень специфично от сервера к серверу. А Вы никогда не задавались вопросом - почему в других СУБД (Oracle, IBM DB2, Sybase ASA, Sybase ASE) уже как сто лет существует поддержка Java (внешние ХП, хранение обьектов Java в таблицах, возможность их использования в ХП и т.д.) - и это никем массово не было востребовано ? И вроде везде толково реализовано и народ Java вроде как знает. Почему у меня сейчас на сервере стоит СУБД ASA, в которой берешь Java и делаешь что хочешь в БД, а я ни разу даже не попытался Java там запустить ? Надо думать на все эти вопросы будет 2 ответа: 1. "Повода не возникало"(прямо как в анекдоте про мальчика, который молчал) 2. Затраты на реализацию и сопровождение бизнес-логики работы с данными родным диалектом языка ХП гораздо ниже, чем на ООП языке Ну так неужели включение в MSSQL поддержки .NET резко ускорит разработки на нем, выведет на новый уровень, даст большие возможности по манипуляции и обработке данных ? Пока я лично вижу одно применение этой фичи - на ней будет удобно делать то, что "случайно" забыли реализовать в TSQL и обходить различные баги СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 14:08 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2 ASCRUS Садись, ПЬЯТЬ! ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 14:10 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2ASCRUS вы не правы. рассказывать где я видел не буду, смысла мало. более серьозно выглядет то что оракл часть своих модулей для OEBS разрабатывал используя и джаву (ту что в субд). в Collbaoration Suite & Oracle workflow тоже для большинства фич продублированы pl/sql апи и java. сильно сомневаюсь что они это делали просто для маркетинговой галочки. все отлично понимают насколько убог pl/sql и что это должно как-то изменится, просто никто незнает как. примерно как с гридами, все понимают что полезности пока от них мало, но в то же время уверены что за ними будущее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 14:18 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
ASCRUS2. Затраты на реализацию и сопровождение бизнес-логики работы с данными родным диалектом языка ХП гораздо ниже, чем на ООП языке Вот этот "тонкий" момент MS и хочет обыграть, и есть вероятность, что это ей удасться лучше конкурентов, потому как все свое и системы разработки/отладки замечательно друг в друга интегрируются. ASCRUSПока я лично вижу одно применение этой фичи - на ней будет удобно делать то, что "случайно" забыли реализовать в TSQL и обходить различные баги СУБД.Ну, не знаю... А я вот хотел бы видеть в этом то, что при написании той же ХП, я бы логику и переменные описывал бы на привычном "мне" подмножестве .NET диалектов: С#, Delphi.NET, а не вспоминал бы каждый раз как это я там последний раз извращался на T-SQL. А SQL Server занимался бы тем, чем должен - выполнением и оптимизацией собственно SQL и возвращением или модификацией набора данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 14:31 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2 Yo! Вы ОЧЕВИДНО крупный специалист по ЭТОМУ вопросу ;) Было-бы ОЧЕНЬ интересно послушать НАСКОЛЬКО убог PL/SQL ? И самое главное ЧЕМ ??? Зарание СПАСИБО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 14:43 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)2 Yo! Вы ОЧЕВИДНО крупный специалист по ЭТОМУ вопросу ;) Было-бы ОЧЕНЬ интересно послушать НАСКОЛЬКО убог PL/SQL ? И самое главное ЧЕМ ??? Зарание СПАСИБО. Плохой танцор - хороший папа! (надеюсь оригинал все знают) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 15:32 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторВы ОЧЕВИДНО крупный специалист по ЭТОМУ вопросу ;) Было-бы ОЧЕНЬ интересно послушать НАСКОЛЬКО убог PL/SQL ? И самое главное ЧЕМ ??? всем, нет ассоциативных масивов, те зачатки в виде колекций вызывают только задражение, т.к. инструменто для работы с ними нет. как язык pl/sql не развивается уже лет 7. нука просветите меня что было добавлено в язык за последнии 7 лет ? ничего стоящего - даже perl и php гораздо прродвинутей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 15:47 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
LeonidА я вот хотел бы видеть в этом то, что при написании той же ХП, я бы логику и переменные описывал бы на привычном "мне" подмножестве .NET диалектов: С#, Delphi.NET, а не вспоминал бы каждый раз как это я там последний раз извращался на T-SQL. А вот это и есть ключевая фраза - психологический момент восприятия принципов работы с технологиями. Вместо того, чтобы осознать бесполезность багажа известной технологии в какой то другой, частенько предпринимаются попытки "подогнать" средство под свое привычное мировозрение, далее затратив кучу усилий и полностью осознав мудрое назначение поговорки "Чем дальше в лес, тем больше дров", остается или признать себя дураком и все таки начать думать по другому или же обвинить во всех смертных грехах неподдающуюся технологию. Из наиболее таких ярких примером мне встречались связки перехода специалистов FoxPro/Delphi->логика на SQL, Access/VB->Delphi, Delphi->Java, Delphi->PowerBuilder, можно было смеяться и плакать одновременно, одновременно удивляясь упорству. Тут как раз в тему вспоминается анекдот о том, как сотрудникам вручили квадраты с заданием вложить их в маленькие шарики и по результатам тестов было определено, что половина из сотрудников глупые, а половина очень сильные (за дословность не ручаюсь) :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 15:57 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Yo! авторВы ОЧЕВИДНО крупный специалист по ЭТОМУ вопросу ;) Было-бы ОЧЕНЬ интересно послушать НАСКОЛЬКО убог PL/SQL ? И самое главное ЧЕМ ??? всем, нет ассоциативных масивов, те зачатки в виде колекций вызывают только задражение, т.к. инструменто для работы с ними нет. как язык pl/sql не развивается уже лет 7. нука просветите меня что было добавлено в язык за последнии 7 лет ? ничего стоящего - даже perl и php гораздо прродвинутей. Ооо, Вы действительно крупный специалист :) ассоциативные массивы ЕСТЬ (и даже по не числовому индексу) и я ими как и коллекциями, автономными транзакциями, временными таблицами, обработкой исключений, пакетами, партиционированием, всевозможными видами триггеров на все что шевелится и т.д. и т.п. АКТИВНО пользуюс в работе. По поводу новых возможностей почитайте списки фич, публикуемые с каждым новым релизом. Уверяю Вас, их добавлено немало. Очевидно, про то, что PL/SQL работает гораздо более оптимально (например в части снижения количества мягких разборов) ВАМ говорить БЕСПОЛЕЗНО, бисер дорог ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 16:11 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Имелось в виду PL/SQL работает корректнее Явы. По крайней мере при одинаковых затраченных усилиях на написание и отладку кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 16:17 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 16:19 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Yo! авторВы ОЧЕВИДНО крупный специалист по ЭТОМУ вопросу ;) Было-бы ОЧЕНЬ интересно послушать НАСКОЛЬКО убог PL/SQL ? И самое главное ЧЕМ ??? всем, нет ассоциативных масивов, те зачатки в виде колекций вызывают только задражение, т.к. инструменто для работы с ними нет. как язык pl/sql не развивается уже лет 7. нука просветите меня что было добавлено в язык за последнии 7 лет ? ничего стоящего - даже perl и php гораздо прродвинутей. Дык и C++, однако, последние 6 лет то-же не развивается. На помойку его? Тогда посоветый это MicroSoft, а то они бедняги, до сих пор на нем пишут... Ну а насчет PL/SQL, коль не дошло, то: ПЛОХОМУ ТАНЦОРУ - ЯЙЦА МЕШАЮТ ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 16:20 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
По поводу множества ценнейших операций с массивами php:как насчет того, что часть из этого должна быть сделана на sql?Уж явно sort_array проще заменить на order by или вы любить делать хитрые fetch основываясь на упорядоченности исходного массива или php имеет оптимизатор с индексами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 16:32 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
ASCRUSА вот это и есть ключевая фраза - психологический момент восприятия принципов работы с технологиями... Странно Вы рассуждаете. Несовсем понял про переходы, ну да ладно. Возвращаясь к теме, я вот не пойму, что вы держитесь за T-SQL как надстройку? Чем лучше этот "клей" между SQL операторами, чем полнофункциональный язык, не пойму? Я не со стороны рассуждаю. Мне очень часто приходится писать на T-SQL большие процедуры и я, поверте, знаю что говорю. Нет стандарта на T-SQL так же как нет стандарта на PL/SQL и другие диалекты. Зато есть худо-бедно стандарт на сам SQL и его-то и нужно придерживаться производителям SQL серверов. Скажем, простой пример из моей практики: нужно было реализовать в MSSQL стандартную ф-цию перевода цисла в его словесное представление. Ф-ция давно была написана и отлажена на Delphi. Можно было подключить ее через DLL, но, по некоторым соображениям, пришлось перевести ее на T-SQL, потратив на это определенное время и усилия - какой смысл?. В случае с Yukon и .NET-языка, мне достаточно написать эту ф-цию один раз и работать она будет быстрее, что существенно, если я захочу запихать ее в SELECT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 16:35 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2 Yo! Вы должны быть очччень хорошим папой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 16:40 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
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. Скажем так - сумма прописью обычно реализуется на клиентском приложении и сие я могу только назвать извратом (без обид) :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 16:47 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
>Скажем, простой пример из моей практики: нужно было реализовать в MSSQL стандартную ф-цию перевода цисла в его словесное представление. Ф-ция давно была написана и отлажена на Delphi. Можно было подключить ее через DLL, но, по некоторым соображениям, пришлось перевести ее на T-SQL, потратив на это определенное время и усилия - какой смысл?. В случае с Yukon и .NET-языка, мне достаточно написать эту ф-цию один раз и работать она будет быстрее, что существенно, если я захочу запихать ее в SELECT. на SQL, это дело можно реализовать так, чтобы работало достаточно производитльно. Плавал я в этих морях, знаю о чем говорю. Хотя это только часть задачи. Есть еще и валюты, и их склонения должны быть в этом случае написаны правильно. Типа одна тысяча пятьсот долларов 50 центов ) еще и справочник валют нужен...)) а справочник - это табличка в базе данных... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 17:10 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
ASCRUSЭто "клей" позволяет Вам быстро и эффективно реализовывать бизнес-логику в БД, где вся бизнес-логика - это цепь операций с множествами. Чем "полнофункциональный" язык будет выгодней в данном плане я лично не понимаю.Да тем и будет выгоднее, что он полнофункциональный и операции с множествами ни куда не пропадут. ASCRUSА я не со стороны могу заявить, что процедуры не могут быть сильно большими, как не могут быть сильно вложенными, с большим кол-вом переменных, циклов или переменных. Если это наблюдается, значит проблемы в проектировании БД.Давайте не будем про проблемы в проектировании, а? Вы что думаете, кроме Вас здесь все дураки собрались (без обид). Еще какие могут быть большие и со сложной логикой. Пример - построение сложных отчетов. ASCRUSЧто будем брать за стандарт - SELECT, INSERT, UPDATE, DELETE ? Долой рекурсивные запросы, долой времянки, долой триггера, ХП и т.д., так как у каждой РСУБД это свое ? Может тогда и долой транзакции, чтобы не путаться между блокировочниками, версионниками и особенностями их реализаций для каждой СУБД?Ну почему долой? Почему?! Ни кто их у Вас не отбирает. Не передергивайте, пожалуйста! Вам просто заменяют "клей" на более универсальный. Хотите, пользуйтесь старым "клеем". Вы бы почитали сначала статьи от самого MS на сайте MSDN по поводу как это будет в Yukon, а потом бы уже кричали, что вам из этого нужно/не нужно. А то я боюсь, вы имеете поверхностное представление. ASCRUSСкажем так - сумма прописью обычно реализуется на клиентском приложении и сие я могу только назвать извратом (без обид) :)Представте себе, существуют системы на SQL серверах, которые могут выполнять многие действия как то, например, подготовку отчетности и вывод ее и без "клиента" и это не такой уж изврат, поверте. Это лишь частный, может и не лучший, пример интеграции полнофункционального языка в SQL. Гораздо более интересна перспектива более простого создания бизнес логики прямо на сервере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 17:18 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Я никогда и не утверждал, что это не нужно. Мы вроде как начали с того, что для начала было бы неплохо довести до ума то, что есть в MSSQL, а потом уже заниматься его расширением и интеграцией с другими продуктами ? И передергиваю не я, так как мой комментарий шел к Вашему высказыванию по поводу "Ну его TSQL, на C# писать выгоднее". Плохо, когда производитель ПО мечеться из стороны в сторону, периодически устраивая у себя революции, именно по этой причине я не люблю работать с продукцией MS и Borland, хотя "любить" и "работать" конечно же разные понятия. авторГораздо более интересна перспектива более простого создания бизнес логики прямо на сервере. Как я уже говорил выше, это вроде и сейчас возможно во многих РСУБД на Java, поэтому в встраивании такой возможности в MSSQL в 2005 году (если у MS опять накладок не случится) поводом восторгаться и радоваться не вижу, тем более утверждать насчет весомых аргументов над Ораклом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 17:39 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
ASCRUSЯ никогда и не утверждал, что это не нужно. Мы вроде как начали с того, что для начала было бы неплохо довести до ума то, что есть в MSSQL, а потом уже заниматься его расширением и интеграцией с другими продуктами? И передергиваю не я, так как мой комментарий шел к Вашему высказыванию по поводу "Ну его TSQL, на C# писать выгоднее". Да, мне как разработчику выгоднее. Ну доведут они до ума T-SQL и что? Мне как разработчику все равно придется помнить кроме SQL, его к тому времени раздутую вплоть до ООП Transact-составляющую, а при переходе на ORACLE его раздутую PL-составляющую. Хороший пример с VB, который сейчас лицензируют все кому не лень, и правильно делают. Те же Corel, AutoDesk встраивают в свои продукты поддержку VB в качестве "клея" - очень удобно для унифицированного скрипто-писания под Win. ORACLE, кстати, на сколько мне известно, тоже будет поддерживать .NET Возможно, правда, не так хорошо и тесно, как MSSQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 17:56 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Нету стандарта SQL, нету. Нечего придерживаться. Т.е. стандарт-то есть, но ограничиваясь только им ничего не напишешь. Короче, идея писать на бейсике, пользуясь только "стандартной частью" TSQL абсолютно утопична. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 18:05 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
MasterZivНету стандарта SQL, нету. Нечего придерживаться. Т.е. стандарт-то есть, но ограничиваясь только им ничего не напишешь. Ну так плохо это, плохо. Вместо того, чтобы развивать стандарт SQL, каждый тянет одеяло на себя. Но подвижки есть тем не менее. ORACLE и тот к JOIN-ам пришел наконец-то. MasterZivКороче, идея писать на бейсике, пользуясь только "стандартной частью" TSQL абсолютно утопична. Да никто и не предлагает писать на "стандартной части" TSQL склеивая это бейсиком. Просто большую часть Transact-составляющей можно перенести на плечи .NET, а не развивать параллельно по сути еще один язык. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 18:17 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Хотелось бы увидеть практический пример реализации хотя бы примитивной бизнес-логики: код на TSQL и аналогичный код на C#, где сразу бы в глаза бросались преимущества последнего. А пока рассуждения идут в пользу бедных, если бы да кабы :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 18:56 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
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. А это на TSQL: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Код: plaintext 1. 2. 3. 4. 5. 6. 7. Код: plaintext 1. 2. 3. 4. 5. 6. 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 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2004, 19:19 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Триггеры before и другие обсуждались вот тут: http://www.sql.ru/forum/actualthread.aspx?tid=27979 2 Leonid >Можно было подключить ее через DLL, но, по некоторым соображениям, пришлось перевести ее на T-SQL, потратив на это определенное время и усилия - какой смысл? Действительно, нет смысла. Может все-таки нужно было подключить через DLL? DLL это такой же механизм для интеграции приложений (тоже революционная технология, много шума было когда-то), как сейчас .НЕТ. После выхода Юкона (если вдруг) тоже можно будет сказать: можно было написать на C#, но, по некоторым соображениям, пришлось перевести ее на T-SQL. "Некоторые соображения", как известно, от языка программирования не зависят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 04:47 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
>>Мне как разработчику все равно придется помнить кроме SQL, его к тому времени раздутую вплоть до ООП Transact-составляющую, а при переходе на ORACLE его раздутую PL-составляющую. Ну и что? От разработчиков всегда требуется что-то помнить. Такова жизнь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 06:49 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
>> Скажем, простой пример из моей практики: нужно было реализовать в MSSQL стандартную ф-цию перевода цисла в его словесное представление. Ф-ция давно была написана и отлажена на Delphi. Можно было подключить ее через DLL, но, по некоторым соображениям, пришлось перевести ее на T-SQL, потратив на это определенное время и усилия - какой смысл?. Вот потому, что такие функции на сервер тащить не стоит, и не следует включать .NET в MSSQL. Потому, что все скриптописатели сразу начнут тянуть все своё незаменимое творчество на сервер. А смысл? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 06:57 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
www.fun4me.narod.ruВот потому, что такие функции на сервер тащить не стоит, и не следует включать .NET в MSSQL. Потому, что все скриптописатели сразу начнут тянуть все своё незаменимое творчество на сервер. А смысл? Мне вот интересно другое - MS же должна понимать, что развязывая руки кодерам в MSSQL и давая им такое мощное средство, как C# и CLR, она просто ставит под удар такие характеристики, как надежность, скорость и безопасность. Уже видны толпы радостно потирающих руки кодеров, с высказываниями типа - "Наконец то мы в БД все реализуем как привыкли в Access/Delphi/etc". Исходя из этого можно ожидать на сегменте баз данных MSSQL необычайно мощного всплекса криво реализованных БД, собственных велосипедов обработки и хранения данных в БД (вот уж где будет соблюдение "одного стандарта программирования"), вирусов хранимых-процедур и много чего еще интересного. С моей точки зрения для MS , которая специально в те же UDF ввела множество ограничений для борьбы с велосипедистами в MSSQL 2000, такая смена политики выглядит довольно странно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 07:47 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
А ведь так можно и Mono в MySQL запихать! Вот зверь получится!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 09:42 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
вообще, согласен с мнением, что CLR в SQL Server - это кратчайший путь к созданию кривых в общей массе баз данных. меня не удивляет то, что некоторые пытаются сделать все на уровне приложения, а не БД. Это говорит лишь о слабом знании самого сервера БД, его возможностей. Я думаю, наивно было бы полагать, что доморощенный Кулибин сделает построит более эффективный план запроса, чем оптимизатор сервера БД. С другой стороны внесение возможностей CLR, Java внутрь сервера БД в определенных случаях может значительно помочь в том случае, когда у архитектора проекта есть голова на плечах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 13:21 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
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. Сервер приложений будет гораздо легче интегрировать с БД. По сути он там может и находится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 14:04 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
LeonidЯ, например, уверен, что с интеграцией .NET в MSSQL, будет проще создание многозвенных БД на базе MSSQL. Сервер приложений будет гораздо легче интегрировать с БД. По сути он там может и находится. Хм. По мне, идея интеграции AS в БД несколько сомнительна. Идея "многозвенности" - как раз в том, что AS - это приложение, работающее с БД, и единственное, видимое "снаружи". Другой вопрос - что этим путем можно будет легко создавать "БД, которые на самом деле не только БД" - к примеру, те же view, содержимое которых ограничено правами пользователя и рассчитывается с использованием возможностей appserver-а. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 14:25 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
LeonidОпять глупость какая-то. Кривость БД не пропорциональна заложенным в сервер возможностям. В таком случае, самые кривые решения должны быть на ORACLE ;)Именно такое впечатление и складывается. На MS SQL курсоры медленны - все стараются обходится без них. В ORACLE - лепят где нужно и где не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 14:34 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
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. А вообще не понимаю, чего так горячиться и обвинять других в глупости ? Неужели Вы думаете, что я настолько туп и недальновиден, что не вижу выгод при использовании ООП языков в БД ? В данном случае мне не интересны преимущества, их и так понимает любой граммотный проектировщик БД, мне гораздо интереснее последствия :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 14:47 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
?На MS SQL курсоры медленны - все стараются обходится без них. В ORACLE - лепят где нужно и где не нужно. От обратного - в MSSQL все лепят времянки где нужно и не нужно ;-) И не понимают, как в Оракле большинство обходится без них. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 15:28 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
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А вообще не понимаю, чего так горячиться и обвинять других в глупости ?Давайте не будем горячится, кто против, тем более нам с вами делить особенно не чего ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 15:33 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
>> И, потом, ни чего особенно уж сложного в стандартном SQL нет, а необходимость знания реляционной модели при работе с SQL-Server-ами никто не отменит. А в С++ разве что-то особенно сложное есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 15:37 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
www.fun4me.narod.ruА в С++ разве что-то особенно сложное есть?Вы сами знаете ответ. Точно так же нужны знания и практика ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 15:57 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
есть неоспоримый факт что существует достаточно большая часть программеров которые совершенно не вникает в работу субд. мало того это от него специально скрывают различные фреймворки и корпоративные буилдеры. эти люди пишут серийные системы обслуживающие крупнейшие канторы, т.е. их системы в разы комплекснее чем системы большинства из вас. да есть проблема производительности у таких изделий, но при определеных размерах проэкта это решается грубой силой (железом). короче мысль в том что те кто и так логику вынес на апп-сервер, получит бонус в виде переноса оной на ближе к уровеню субд и получив еще пару процентов к скорости, а те кто бьется за каждый запрос, так и будут использовать T-SQL (PL/SQL). просто как видно по ораклу он потехоньку забивает на pl/sql (7 лет косметические изменения) и теперь очень медлено его развивает, в то время как 10gR2 жаба продвинута до версии 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 16:12 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Yo!есть неоспоримый факт что существует достаточно большая часть программеров Этот баян мы недавно обсуждали... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2004, 16:17 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
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#. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2004, 03:17 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
большинство высказываний защитников ORACLЕ находиться на уровне эмоций: SQL-Server - отстой, а Б. Гейтс - козел по определению, следовательно пользоваться его продуктами не будем, а кто пользуется - лохи позорные. Видали мы таких - рвут глотку, что винда - тормозная и незащищенная по сравнению с *nix , а сами с ХР не слазят. Если вы привыкли к oracle и не хотите пользоваться MSSQL, которая по сути не лучше и не хуже, так честно так и скажите, а не наезжайте на новые возможности системы, только потому, что ненавидите microsoft. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2004, 15:39 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Ну кто сказал что мы ненавидим M$? В принципе - хорошая ОС. Но вот политика M$ в области продвижения своего ПО не всегда чистоплотна (хотябы в отношении Линукс). У ПО от M$ полно недостатков, в некоторых аспектах оно хуже и отстает от ПО других производителей, которые разрабатывают софт на их же платформе. Конечно же M$ никуда не денется ближайшие годы, но однако потесниться придется, причем основательно. Время покажет. -- Да здравствует Линукс! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2004, 16:47 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2 g >большинство высказываний защитников ORACLЕ находиться на уровне эмоций: SQL-Server - отстой, а Б. Гейтс - козел по определению, следовательно пользоваться его продуктами не будем, а кто пользуется - лохи позорные. Это аргументированно, с выдержками и цитатами и без лишних эмоций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2004, 00:34 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
gardenman Конечно же M$ никуда не денется ближайшие годы, но однако потесниться придется, причем основательно. Время покажет. Дык время то вроде как раз наоборот показывает - MS остальных теснит :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2004, 01:24 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
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, а людей, которые сами скачивают бесплатные дистрибутивы и компилят их, не так много, я например себе занятие поинтереснее найду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2004, 11:48 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2g я смотрю вы тут новенький, поэтому чтоб не выглядеть дурачком потрудитесь просмотреть соседние топики, там достаточно подробно рассписаны все аргументы, по всем вопросам. начиная от уровней изоляции заканчивая кластерами. повторять одно и то же в каждом топике большинству задолбало, хотя упорно пару лет это делали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2004, 13:16 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
g - забудте в этой ветке про Linux. На данный момент обсуждаемые СУБД имеют свои излюбленные платформы MSSQL - Win2k, 2k3 Oracle = unix(solaris, ..). Oracle на Linux держат в 99% для тестовых систем. А тот же Solaris не такая пионерская разработка, как Вы пытаетесь нам преподнеси. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2004, 18:48 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
hell Oracle на Linux держат в 99% для тестовых систем. Наша фирма начала ставить закачикам Оракл на Linux. Т.е. раньше были видны, но при установке новой версии инф. системы ставят Linux. Ну и для разработки на фирме 2 сервера на Linux, Один старый на Виндах. Правда много ораклов на клиентских компах на виндах - потому, что на серваке возникают неприятные накладки - один снес что-то из БД, а там были разрабатываемые объекты коллеги (у нас несколько разных проектов). У заказчиков для БД Одна Open VMS, один UNIX - это требования заказчика. Один заказчик раньше перешел с UNIX на Винды из-за того, что передали систему для администрирования тамошним АСУ-бщикам, а те не знают UNIX и потредовали перевода на Винды серверов. Хорошо, что Ораклу по барабану ОС. Конечно, если не обращать внимания, что там свои баги могут быть. Но вроде пока не напрягает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2004, 20:29 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
vadiminfo hell Oracle на Linux держат в 99% для тестовых систем. Наша фирма начала ставить закачикам Оракл на Linux. Т.е. раньше были видны, но при установке новой версии инф. системы ставят Linux. Ну и для разработки на фирме 2 сервера на Linux, Один старый на Виндах. Правда много ораклов на клиентских компах на виндах - потому, что на серваке возникают неприятные накладки - один снес что-то из БД, а там были разрабатываемые объекты коллеги (у нас несколько разных проектов). У заказчиков для БД Одна Open VMS, один UNIX - это требования заказчика. Один заказчик раньше перешел с UNIX на Винды из-за того, что передали систему для администрирования тамошним АСУ-бщикам, а те не знают UNIX и потредовали перевода на Винды серверов. Хорошо, что Ораклу по барабану ОС. Конечно, если не обращать внимания, что там свои баги могут быть. Но вроде пока не напрягает. Это как это много оракла на клиентских компах? Каждому разработчику по базе что-ли? Для тестирования и сборки релизов у вас должна быть отдельная база, где у разработчиков прав нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2004, 20:41 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
killed Это как это много оракла на клиентских компах? Каждому разработчику по базе что-ли? Для тестирования и сборки релизов у вас должна быть отдельная база, где у разработчиков прав нет. На клиентских для разработки своих задач. Но там по одной-две БД. Не у всех разработчиков конечно. А у меня так еще и дома. На серверах несколько БД по разным проектам. Например, эти празники для тестирования и настроек закчиваю в одну такую в две таблы по 30 миллионов записей. Конечно, такого на клиентском компе нет возможности провернуть. Кроме того, мы и есть разработчики - т.е. и разработчики БД. К сожалению, у заказчика реализовали уже кластер с рейдами, а этого нет сейчас на фирме. Те кто проектировали торопились или что (не дотестировали), но теперь там у заказчика что-то тормозит, а мне дали задание решить этот вопрос. Так что тестирование идет не на полном аналоге. Т.е. у нас много баз для тестирования, а той что надо (в плане физической реализации) для выполнения моего задания нет. Возможно, придется еще ехать самому к заказчику и там разбираться, а очень неохота, и денег фирмы жалко (итак этим летом не было большой премии). Одно дело, то что в книгах написано про то как должно быть, а другое то с чем приходится сталкиваться в реальности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2004, 21:36 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
vadiminfo killed Это как это много оракла на клиентских компах? Каждому разработчику по базе что-ли? Для тестирования и сборки релизов у вас должна быть отдельная база, где у разработчиков прав нет. На клиентских для разработки своих задач. Но там по одной-две БД. Не у всех разработчиков конечно. А у меня так еще и дома. На серверах несколько БД по разным проектам. Например, эти празники для тестирования и настроек закчиваю в одну такую в две таблы по 30 миллионов записей. Конечно, такого на клиентском компе нет возможности провернуть. Кроме того, мы и есть разработчики - т.е. и разработчики БД. К сожалению, у заказчика реализовали уже кластер с рейдами, а этого нет сейчас на фирме. Те кто проектировали торопились или что (не дотестировали), но теперь там у заказчика что-то тормозит, а мне дали задание решить этот вопрос. Так что тестирование идет не на полном аналоге. Т.е. у нас много баз для тестирования, а той что надо (в плане физической реализации) для выполнения моего задания нет. Возможно, придется еще ехать самому к заказчику и там разбираться, а очень неохота, и денег фирмы жалко (итак этим летом не было большой премии). Одно дело, то что в книгах написано про то как должно быть, а другое то с чем приходится сталкиваться в реальности. Если честно, это все малоубедительно. По-моему опыту, чем больше исключений из правил - тем больше хаоса при разработке. А еще я убежден, что грамотный разработчик, если он считает себя профессионалом, будет работать в рамках общего полиси, не изобретая велосипед. Почему? Потому что он знает, что съэкономит себе массу времени. Другое дело, когда такого полиси нет у компании, но это уже ваша вина. По поводу rac, raid и т.д. А откуда уверенность, что проблема именно в "физике"? Это мне кажется вообще аутскоп для разработчиков. Я бы к примеру для начала попросил клиента выслать экспортированную статистику. Применить ее на базе (опять таки на базе для целей QA) и протестировать функционал. В любом случае, сделать "полный аналог" - имхо нереальная задача. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2004, 22:04 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
killed Если честно, это все малоубедительно. По-моему опыту, чем больше исключений из правил - тем больше хаоса при разработке. А еще я убежден, что грамотный разработчик, если он считает себя профессионалом, будет работать в рамках общего полиси, не изобретая велосипед. Почему? Потому что он знает, что съэкономит себе массу времени. Другое дело, когда такого полиси нет у компании, но это уже ваша вина. Разумеется это не убедительно. Но что делать? Просто у разных проектов разные требования. В одних случаях это проходило, а в других нет. Если бы я вел тот проект, то перезаложился бы на проверках. Но что значит полиси, когда каждый проект по своему уникален? На то он и проект. Другое дело выполнение некоторых общих рекомендаций известных методологий по проектированию ИС. Но это решение руководителя конкретного проекта. У фирмы есть стандарты, но в тестировании явно они кое-что упустили. А меня никто не спрашивал - мое дело выполнять задания, а не рассуждать о том как надо было все делать. Хотя протолкнуть в стандарты полномасштабное тестирование БД буду пробовать после этого случая. killed По поводу rac, raid и т.д. А откуда уверенность, что проблема именно в "физике"? Это мне кажется вообще аутскоп для разработчиков. Я бы к примеру для начала попросил клиента выслать экспортированную статистику. Применить ее на базе (опять таки на базе для целей QA) и протестировать функционал. В любом случае, сделать "полный аналог" - имхо нереальная задача. Я имел в виду, что если бы тестирование было один к одному, то я бы чувствовал себя более уверенно. Я бы проверил те исправления на реальном варианте, и их бы выполнили удаленно или те кто туда ездит. А так может не повезти и там окажется что-то другое. Может и не с Ораклом связанное, наряду с причинами Оракловыми. Например, что-то левое ресурсы хапает. То что физика играет роль для тестирования достойно учета. Например, уже есть показания перенести журналы повторного выполнения лучше на другой диск на этом серваке, а там рэйды и таких ожиданий может и не быть. Там показатели I/O другие - много выше. Конечно, все что касается приложения будет проверено, но пойдут ли на исправления не известно. Например, уже есть подозрения на чрезмерные коммиты. Что касается статиситки, то ее сбор там еще надо организовать. Кроме того, для выявление конкретных причин нужно отлавливать чего ожидает сессия в момент, когда тормоза явно видны. Ну и все такое. Возможно все это придется сделать (там организовывать сбор статистики и ждать когда тормознется), после того как въеду в особенности работы БД в этом проекте. Но очень хочется, чтобы обошлось без этого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2004, 23:49 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2 g Не вырывайте высказывания из контекста, это глупо и может сработать разве что в детском саду в песочнице. Вполне нормальные аргументы, если не лениться читать. Я тоже объяснил почему считаю что C# в качестве языка программирования SQL серверов не приживется. Хранение запросов в виде строк с проверкой синтаксиса и пр. во время исполнения работает только когда таких запросов относительно немного. На SQL серверах запрос - основное средство работы, строк с запросами чуть ли не больше, чем строк без запросов. Кроме того еще, предлагается увеличить это количество втрое. Поэтому должен быть специализированный язык или хотя бы препроцессор как у ДБ2, оракла и сайбейза, а джава или C# для этой задачи неудобны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 02:28 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Надо для СУБД вместо CLI использовать какой-нибудь DPLI /*Data Processing Lanuage Infrastructure*/, который должен быть расширнием CLI и в которм будут хранится разобранные запросы. Тогда быстро работать всё будет. А если DPLI подключить к Mono и присобачить к MySQL, то хранимые процедуры будут переносимы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2004, 08:43 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
позвольте и мне пару ложек. Вот тут мнения такие наблюдаются: авторЗачем перегружать СУБД излишней бизнес-логикой, для этого есть сервера приложений... Правильно, незачем ИЗЛИШНЕЙ перегружать, но существует огромное количество примеро в которых 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. Так что ВЕСОМЫЙ под сомнением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 13:58 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Роман ДынникВозьмем 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. Код: plaintext 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. Роман ДынникНичего она (Java) не мешается, Oracle-у уж точно :), а что касается Sybase дык писать нужно лучше чтоб под ногами java не мешалась. Дык мы и стараемся на Sybase писать так, чтобы Java родимая не мешалась, пользуясь только стандартными и неплохими возможностями WatcomSQL, без загрузки сервера кушающей память JVM :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 16:15 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторА чем не устраивает стандартно для клиента открыть транзакцию, записать мастер, записать детайл, подтвердить транзакцию ? Тем что делается несколько вызовов и как следствие - старт транзакции на стороне среднего звена/клиента вместо того что бы стартануть на сервере с последующими возможными проблемы с deadlock-ми. Как вам (100+1) вызов на сохранение счета со 100 позициями? авторНу а если даже уж хочется оптимальным (?) способом, то кто мешает сделать такую ХП: Никто не мешает, я же об этом и говорил. И сам xml активно пользую. Но XML вы этот как получите? Нужно на стороне клиента сеарелизовать java-объект или вручную по объекту собрать XML, правильно? А в случае java-процедуры вы передаете объект без всяких усилий со стороны кода клиента. И второе повышается читабельность кода на стороне СУБД а следовательно и качество поддержки, но это уже на вкус. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 16:43 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
JVM кушает 50М для нормального сервака - это копейки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 16:48 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
>>Никто не мешает, я же об этом и говорил. И сам xml активно пользую. Но XML вы этот как получите? Нужно на стороне клиента сеарелизовать java-объект или вручную по объекту собрать XML, правильно? А в случае java-процедуры вы передаете объект без всяких усилий со стороны кода клиента. << В .NET через SOAP объекты точно так же передаются абсолютно без всяких усилий со стороны разработчика клиентского приложения. А объект по любому сериализовать придётся - что при передаче через RMI, что при передаче через SOAP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 16:58 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Код: plaintext авторА объект по любому сериализовать придётся - что при передаче через RMI, что при передаче через SOAP. Мы говорим не про автоматическую/полуавтоматическую сериализацию (в случае .NET) через SOAP или RMI а про передачу объекта в процедуру через "строковый" параметр XML. Вот чтоб в этот строковый параметр значение(объект в виде XML) запихнуть и нужны усилия со стороны разработчика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 17:13 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Роман ДынникМы говорим не про автоматическую/полуавтоматическую сериализацию (в случае .NET) через SOAP или RMI а про передачу объекта в процедуру через "строковый" параметр XML. Вот чтоб в этот строковый параметр значение(объект в виде XML) запихнуть и нужны усилия со стороны разработчика. Минуточку - так я и привел пример процедуры в СУБД, которая элементарно превращается в SOAP-процедуру, с которой клиентское приложение может работать через тот же 80 порт на получение и передачу данных, вообще не используя никаких ODBC, JDBC, ADO.NET и прочего. А с клиентских приложений по моему все кому не лень могут с XML и веб-сервисами работать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 17:22 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
автор через тот же 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. Как вы думаете, с производительностью все нормально будет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 17:54 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Роман Дынник автор через тот же 80 порт работа с сервером ч/з HTTP/S - это еще одна ОЧЕНЬ длинная песня, тут можно и про безопасность тему развить и производительность сравнить и про целесообразность погорорить... Я еще пример приведу. Допустим для какого то класса у вас глубина наследования равная 5. Соответственно на сервере, если CRUD в слое хп вам надо выполнить: Код: plaintext 1. 2. 3. 4. и в каждой процедуре делать OPENXML. Как вы думаете, с производительностью все нормально будет? Ну во первых кто мешает вызывать просто sp_Ins5(@xml), передавая туда сразу все аттрибуты класса и его предков ? Во вторых Вы пытаетесь на РСУБД наложить ООП, а при моем подходе это просто ни к чему. Зачем спрашивается на уровне клиента плодить бизнес-классы, если вся бизнес-логика лежит на СУБД и от клиента требуется ума только получить данные в виде набора данных, показать их для просмотра, организовать их отложенное изменение и потом пакетно сохранить все изменения ? Для организации такой работы в любой среде построения клиентов сейчас существуют стандартные компоненты доступа к данным, их визуального просмотра и построения отчетов. Этого вполне достаточно, чтобы организовать клиента в виде GUI приложения или интернет-проекта. В данном случае по моему личному мнению ООП будет использоваться по прямому его назначению - быстрой организации и легкой поддержки интерфейсной части. Всякие попытки перенести бизнес-обьекты на классы и потом танцевать с бубном по проведению их хранения и эффективности обработки на РСУБД только усложняют задачу. В конце концов при автоматизации какой то задачи у нас нигде в постановке нет задания создать аналог реального отображения обьектов. Нам всего то нужно обеспечечить хранение и обработку информации (именно информации, а не обьектов), где лучше всего подходят РСУБД и организовать удобный интерфейс работы с пользователем, где ООП очень полезна в плане создания повторно-наследуемых форм, компонент и других интерфейсных частей приложения. И тут, как только мы данные РСУБД начинаем рассматривать именно как информацию, а не понятно для чего нужные обьекты, все становиться на свои места. Плюс не понятно, что именно должно наследоваться в бизнес-обьектах - если какие то аттрибуты и логику сущностей можно выделить единым целым, то на "Один-ко-Многим" это все прекрасно реализуется по таблицам, триггерам, представлениям и хранимым процедурам по нормальным формам. Так что лично для меня понятия "Сущности-Аттрибуты" гораздо лучше ложаться на ТЗ поставленных задач, чем "Классы-Обьекты-Свойства". Единственный существенный недостаток, присущий кстати как РСУБД, так и ООП - это строгая формализация данных, где в обоих случаях поддержка обьектов с неизвестным заранее кол-вом аттрибутов будет стоить дополнительных усилий в проектировании и реализации эффективной работы. Опять же мое личное мнение - для этого необходимо вообще разделять данные и код бизнес-логики, причем данные должны быть структурами с произвольным набором аттрибутов определенных в словаре доменов, а бизнес-логика оперировать такими структурами с подходящими по наличию доменов и их значений (где опять же создаются расширяемые словари глаголов по принципам работы функциональных языков) и связывающим звеном для манипуляции множествами является язык запросов. В данном случае очень похоже на продвижение формата XML, хотя куда он двинется и что из этого получится пока не понятно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2004, 19:48 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2 Роман Дынник >Ничего она (Java) не мешается, Oracle-у уж точно :), а что касается Sybase дык писать нужно лучше чтоб под ногами java не мешалась. Так никаких проблем, джава в сайбейзе есть, все замечательно, только использовать ее почему-то никто не хочет. Почему вдруг все дружно игнорируют джаву в SQL сервере? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 04:32 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Код: plaintext Код: plaintext Код: plaintext Код: plaintext Я знаю что вы являетесь поклонником продуктов Sybase... Так вот, PD мне сильно облегчает жизнь в плане написания CRUD, и именно тем что при проектировании БД я использую ОО подход. Весь слой CRUD, а это порядка 70-80% всех хп в проекте генерируется VBSсript-ом на основании концептуальной модели данных, в соответствии с наследованием сущностей и их атрибутами. В некоторых системах используются всякие Persistence/mapping компоненты, которые позволяют автоматически сохранять ОБЪЕКТ в БД (мапить его на sql-выражения) без особых услилий. Т.е. не нужно заботиться о создании слоя хп или прямых запросах. И эти компоненты давно ТАКЖЕ давно стали стандартными (JDO-java data object например). Лично я их не использую, именно потому что не нашел нигде маппинг на хп, но они, в ряде случаев, позволяют значительно сократить сроки разработки для небольших и средних проектов, а также используются в настраиваемых ERP-системах. Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 10:23 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторНу во первых кто мешает вызывать просто 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-системах. авторгде ООП очень полезна в плане создания повторно-наследуемых форм, компонент и других интерфейсных частей приложения. ООП полезно везде. Пора перестать мыслить таблицами и полями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 10:27 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
>>>c127 Не используют потому что не привыкли, потому что мыслят таблицами и записями, потому что надо время на изучение а его нет, потому что не везде целесообразно применять java-процедуры. Если признаться, раньше я и сам задавался вопросом где и зачем они мне могут понадобиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 10:35 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторООП полезно везде. Пора перестать мыслить таблицами и полями. Да-да, и еще пора опять переносить бизнес-логику на клиента, делать в каждой системе обязательное среднее звено, доступ к БД может быть только через клиента или среднее звено...... А может все же облегчить себе жизнь? Иногда нужно помыслить таблицами и полями - проще жить станет, намного проще. А еще ООП не надо переносить на данные и вообще на все, что шевелится :) - это технология разработки и программирования приложения, но никак не технология манипулирования данными. Вы расскажите смысл представления данных как объектов? Я вот не вижу. И гораздо проще иметь набор таблиц с полями, с которыми можно сделать что угодно, которые являются родными по отношению к СУБД - и следовательно проще и быстрее их обрабатывать и т.д. В Оракле вот давно есть возможность создавать пользовательские типы данных, с методами, свойствами... Ну и что, много кто ее использует, эту возможность? -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 10:59 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Ну и опять же легкость поддержки системы - если у вас логика зашита в клиента и вам нужно чего-то изменить, но не в выводе информации для клиента, а именно часть бизнес-логики, то вам придется каждый раз компилять клиента и выкладывать пользователям. В случае же бизнес-логики на сервере, ничего никуда ненадо выкладывать - все меняется для всех прозрачно. Вы еще не почувствовали разницу? Может вы просто не пробовали сделать обычное приложение с обычной РСУБД? Попробуйте. Почему всегда забывают про поддержку (изменение, дополнение, исправление) системы??? Хотя это 70% работы. Но на это наплевать? Мда. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 11:03 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Роман Дынник Тем что делается несколько вызовов и как следствие - старт транзакции на стороне среднего звена/клиента вместо того что бы стартануть на сервере с последующими возможными проблемы с deadlock-ми. Как вам (100+1) вызов на сохранение счета со 100 позициями? С уровнями изоляции если правильно работать - то никаких deadlock'ов не будет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 11:13 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
И почему-то все рассматривается со стороны разработчика клиента : мне программировать так удобно, я знаю ООП и больше ничего знать нехочу, всякие там PL/SQL, TSQL учить и знать не хочу да и ваще мне пофиг все эти БД - я же универсальный программист, к СУБД никакого отношения не имею зато смогу сделать под любую БД, у меня же объекты!!! Почему-то забывают про админа/архитектора/разработчика БД, который потом, когда жареный петух клюнет, каким-то образом должен будет разгребать завал, пытаясь поднять производительность, построить индексы, поменять чего еще, если вообще это можно сделать. А забывают зря. Может потому что не знают, что сделать клиента - это 30% дела, а сделать так, чтобы это все работало, да еще без затыков, быстро и т.д. и т.п. - остальная работа. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 11:14 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторВы расскажите смысл представления данных как объектов? Я вот не вижу. И гораздо проще иметь набор таблиц с полями, с которыми можно сделать что угодно, которые являются родными по отношению к СУБД - и следовательно проще и быстрее их обрабатывать и т.д. В Оракле вот давно есть возможность создавать пользовательские типы данных, с методами, свойствами... Ну и что, много кто ее использует, эту возможность? А я и не говорил про создание пользовательских типов данных и ПОЛНОЙ реализации ООП в БД. Я наоборот против этого. Я говорил о способе мышления и как грамотно отразить классы на обычные таблицы с полями с привычними типами данных. Если отбросить среднее звено, клиента, и рассматривать одну лишь БД она НИЧЕМ не будет отличаться. Те же таблицы, типы данных, хп, вьюхи. Просто она будет более формализована, более прозрачна, ее модель будет более понимаема. Вообщем обычная база с таблицами в 3 НФ. Все что там присутствует от ООП - это всего лишь: наследование в виде связи 1-1 методы в виде слоя хп свойств и акцессоров get/set там нет и в помине, события... ну можно в первом приближении с большой натяжкой определить их как триггеры, но триггеры я вообще обычно не использую. авторНу и опять же легкость поддержки системы - если у вас логика зашита в клиента и вам нужно чего-то изменить, но не в выводе информации для клиента, а именно часть бизнес-логики, то вам придется каждый раз компилять клиента и выкладывать пользователям. В случае же бизнес-логики на сервере, ничего никуда ненадо выкладывать - все меняется для всех прозрачно. Вы еще не почувствовали разницу? Может вы просто не пробовали сделать обычное приложение с обычной РСУБД? Попробуйте. я почувствовал... когда в хп была зашита вся бизнес логика... начиная от проверки на допустимость ввода до выполнения cmdshell и вызовов COM. Сервак просто задыхался от выполнения таких процедур. По поводу поодержки - разделяйте код на сборки, модули... Про перенос БЛ на клиенте - я вообще к этому не призывал, я говорил что на клиенте должна ДУБЛИРОВАТЬСЯ проверка корректности ввода данных, это сокращает число повторных обращений к серверу (СУБД или к среднему звену или к веб серверу в случае если клиент - браузер, а проверка корректности ввода на JS). >>tygra, вы вникайте повнимательнее в сообщения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 12:00 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Роман Дынник Сейчас многие так и поступают, именно на РСУБД накладывают ООП, и это правильно, иначе при огромном количестве сущностей поддержка проекта превращается в сущий ад в котором может разобраться только "основной" разработчик. ООП также ничем не упрощает поддержку систем. а вот что сильно упрощает - так это хорошо комментированные исходники и нормальная документация. а ООП или не ООП подход был при разработке системы - это вторичное и совсем не самое критичное. какая разница, что переписывать при добавлении входного параметра в процедуру: саму процедуру и все вызовы к ней при обычном подходе или метод и все его вызовы при ООП? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 12:23 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Давайте разберемся по порядку. А то что-то я уже не понимаю ничего. Давайте только без многозвенок. :) Бизнес-логика. Так где же она? А то что-то в параллель топику про ООСУБД получилось ощущение, что вся БЛ на клиенте/среднем звене. Лично у меня вся БЛ в СУБД, естественно за некоторым исключением или дополнением на клиенте в виде простейшего контроля ввода данных, типа ввели/неввели. Все, больше на клиенте ничего нет. авторА я и не говорил про создание пользовательских типов данных и ПОЛНОЙ реализации ООП в БД. Я наоборот против этого. Тут я тоже против. авторЯ говорил о способе мышления и как грамотно отразить классы на обычные таблицы с полями с привычними типами данных. Зачем???????????? Кто такие классы? Зачем они? авторЕсли отбросить среднее звено, клиента, и рассматривать одну лишь БД она НИЧЕМ не будет отличаться. Те же таблицы, типы данных, хп, вьюхи. Просто она будет более формализована, более прозрачна, ее модель будет более понимаема. Тогда смысл вашего ООП? Хотя как мне кажется, если в БД будут отражаться классы, то все-же не так будет понятно, как если бы структура была изначально сделана как обычно. автор Вообщем обычная база с таблицами в 3 НФ. Все что там присутствует от ООП - это всего лишь: наследование в виде связи 1-1 методы в виде слоя хп свойств и акцессоров get/set там нет и в помине, события... ну можно в первом приближении с большой натяжкой определить их как триггеры, но триггеры я вообще обычно не использую. Зачем вам ООП в данных, ну не понимаю я. Я не вижу смысла городить огород с ООП над данными. если у меня и так все есть и я все могу сделать с данными без проблем. Мне бы пример какой, показывающий разницу :) авторя почувствовал... когда в хп была зашита вся бизнес логика... начиная от проверки на допустимость ввода до выполнения cmdshell и вызовов COM. Сервак просто задыхался от выполнения таких процедур. Так с мозгами делать надо. И не пихать в СУБД то, чего там быть не должно. Можно и на клиенте все так сделать, что он и не запустится :)) авторПо поводу поодержки - разделяйте код на сборки, модули... Какая разница? Все-равно если править в клиенте, то его придется копировать и перезапускать. авторПро перенос БЛ на клиенте - я вообще к этому не призывал, я говорил что на клиенте должна ДУБЛИРОВАТЬСЯ проверка корректности ввода данных, это сокращает число повторных обращений к серверу (СУБД или к среднему звену или к веб серверу в случае если клиент - браузер, а проверка корректности ввода на JS). Ну да, но проверка корректности ввода данных может означать разные вещи. автор>>tygra, вы вникайте повнимательнее в сообщения. Стараюсь. Сбивает мысли соседний топик про ООСУБД, елы-палы :)) ====== И так. Пока что я никак не вижу смысла укладывать данные в ООП структуру. Примеров пока не видел - поэтому больше ничего не могу сказать. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 12:34 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
>>>Tygra's Для примера, какие бы вы таблицы создали для простого справочника клиентов с разделением на физические и юридические лица? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 12:42 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
to funikovyuri авторТем что делается несколько вызовов и как следствие - старт транзакции на стороне среднего звена/клиента вместо того что бы стартануть на сервере с последующими возможными проблемы с deadlock-ми. Как вам (100+1) вызов на сохранение счета со 100 позициями? авторС уровнями изоляции если правильно работать - то никаких deadlock'ов не будет Да? Даже если на 99 вызове внутри одной транзакции стартующей на клиенте/среднем звене неожиданно пропадет соединение с сервером БД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 12:50 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Роман Дынник Рома, среди читающих этот топик, я среди тех кто полностью на вашей стороне. Просто думаю спорить об этом бесполезно (один тигра чего стоит :) ) Да? Даже если на 99 вызове внутри одной транзакции стартующей на клиенте/среднем звене неожиданно пропадет соединение с сервером БД? Да - DEADLOCK 'a не будет. Другой вопрос что приведенный вами пример относиться скорее не к вопросу выбора о том откуда управлять транзакциями (с клиента или с БД), а просто к типичной ошибке проектирования (решается с помощью всем известного патерна facade) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 12:56 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
кстати, незакоммиченные данные на блокировочнике можно перехватить через грязное чтение, правда все никак не дойдут руки, чтоб выложить как это делается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 12:58 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
gardenman далось, блин, это грязное чтение ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 13:06 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторДля примера, какие бы вы таблицы создали для простого справочника клиентов с разделением на физические и юридические лица? А прямо так, как у нас и сделано :) Таблица Клиент, где все данные, относящиеся и туда и сюда: ФИО, мыло, дата, ... в общем, типа такого. И поле Юрлицо - если 0, значит нет, если 1 - значит это юрик, и тогда у него есть реквизиты => А это уже таблица Реквизиты, в которой есть ссылка на Клиента и все прибамбасы: счет, банк и т.д. Вот вроде и все. Когда мне нужен просто клиент - селект фром Клиент. Если нужны реквизиты к тому же - left join Реквизиты. Ну и т.д. Как вы можете прокомментировать? авторРома, среди читающих этот топик, я среди тех кто полностью на вашей стороне. Просто думаю спорить об этом бесполезно (один тигра чего стоит :) ) Да, уж поспорить то я люблю :)). Но тут не спор ради спора - просто хочу узнать, чем лучше или чем хуже данная реализация. Т.к. основные действия (да и почти все вообще) над данными производятся в БД, то какой смысл как-то специально менять их структуру для представления на клиенте? авторкстати, незакоммиченные данные на блокировочнике можно перехватить через грязное чтение, правда все никак не дойдут руки, чтоб выложить как это делается. "Выложу" для MS SQL, так и быть :) Код: plaintext -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 13:16 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Кстати, вспоминая про "весомые плюсы". Источник : 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 13:53 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторТаблица Клиент, где все данные, относящиеся и туда и сюда: ФИО, мыло, дата, ... в общем, типа такого. И поле Юрлицо - если 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, что выполнится быстрее (незачем тащить реквизиты для физического лица). Это по мелочи. В принципе таблица реквизиты у вас тоже самое что и у меня юр/лицо и здесь тоже наследование (таблица Реквизиты, в которой есть ссылка на Клиента и все прибамбасы: счет, банк и т.д). Но явно не выделена сущность "Физическое лицо" и в этом ошибка проектирования. Теперь дальше... Возникло новое требование. Требуется создать справочник сотрудников, при чем сотрудник может быть клиентом. Ваш действия? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 13:55 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
(Роман Дынник) >> тбл. Контрагент (id,краткое наименование, инн) тбл. Физ. лицо (id,Фамилия, Имя, Отчество ...)+fk к контрагенту по id (1-к-1 наследование) тбл. Юридическое лицо/компания (id,Полное наименование, реквизит1, реквизит2 ...)+fk к контрагенту по id (1-к-1 наследование) == Всё-таки плохо, что можно завести контрагента, который будет ни физическим, ни юридическим лицом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 14:03 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Я бы сказал, что контагент - это обобщение понятия физических и юридических лиц. То есть, сначала надо заводить физическое или юридическое лицо. Потом делать ссылку в контрагенте на это лицо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 14:05 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Роман Дынник В ER-нотации есть отношение generalization - так что при желании и знаниях решение будет в точности соответствовать предложенному ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 14:10 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
www.fun4me.narod.ruВсё-таки плохо, что можно завести контрагента, который будет ни физическим, ни юридическим лицом. А кто сказал, что его можно завести? Для этого в Oracle Designer, например, существует специальное понятие "arc" - которое трансформируется в констрейнт примерно следующего вида Код: plaintext автор А У нас так: тбл. Контрагент (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. То есть - постоянные join-ы стоит прятать во вьюхи (естественно, не забывая об эффективности). Во всяком случае, наличие в 50 различных запросах фразы "[Юридическое лицо] JOIN [контрагент]" меня серьезно насторожит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 14:15 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторЯ бы сказал, что контагент - это обобщение понятия физических и юридических лиц Именно это я и хотел сказать. Код: plaintext авторТо есть, сначала надо заводить физическое или юридическое лицо. Потом делать ссылку в контрагенте на это лицо. Это как? т.е. в контрагенте у вас будет 2-а поля одно из которых ссылается на ф/л, другое на ю/л? Это не правильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 14:17 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Господа, только довайте не будем спорить по поводу контрагентов,физиков и юриков.Если есть желание подискутировать по этому поводу, то в ERP и учетных система есть огромный топик по этому вопросу. Вроде бы Oracle и MSSQL обсуждаем... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 14:17 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Ну таблица Контрагент тоже есть, я ее не привел чтобы упростить ответ. А так - да, Контрагент ---> Клиент ---> Реквизиты авторКак же ФИО может относиться и к физ лицам и к юр? И видимо ФИО хранится в одном поле и используется либо как наименование организации, либо как фамилия имя отчество для физ/лица? Ну что вы, как так можно? :) ФИО физлица для Юрика - это фио доверенного лица предприятия. А наименование организации лежит отдельно там где и положено - в реквизитах. авторвидите, только из-за того что вы отвергаете мышление в терминах ООП вы сделали outer join, когда можно было join, что выполнится быстрее (незачем тащить реквизиты для физического лица). Это по мелочи. При чем тут ООП? Я привел left join в качестве примера. Если мне нужны только физлица, то будет так: Код: plaintext Код: plaintext авторВ принципе таблица реквизиты у вас тоже самое что и у меня юр/лицо и здесь тоже наследование (таблица Реквизиты, в которой есть ссылка на Клиента и все прибамбасы: счет, банк и т.д). Но явно не выделена сущность "Физическое лицо" и в этом ошибка проектирования. А тут мне кажется совсем наоборот - у вас есть ошибочка, тут я согласен с www.fun4me.narod.ru :) авторТеперь дальше... Возникло новое требование. Требуется создать справочник сотрудников, при чем сотрудник может быть клиентом. Ваш действия? Ну, этак если дальше пойдет, мы систему тут напишем. Задаром Это уже на усмотрение организации системы. Для чего нужен справочник сотрудников? Как и кто с ними будет работать. Можно заводить сотрудников отдельно, отдельно их как клиентов и связывать с клиентом, можно еще как-то, можно поставить отметку на клиенте о том, что он является сотрудником. Тут никак ООП не может влиять. Хотя вы все-же приведите, как бы сделали вы. ============ www.fun4me.narod.ruЯ бы сказал, что контагент - это обобщение понятия физических и юридических лиц. То есть, сначала надо заводить физическое или юридическое лицо. Потом делать ссылку в контрагенте на это лицо. Или наоборот - при создании клиента сначала создается контрагент, а от него наследуется клиент. Тогда проще будет - хотя бы ID будут одинаковые. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 14:20 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторЧто еще хочется сказать по поводу сказанного Вами - в большинстве подобных задач запрос должен выглядеть как... эти запросы во вью и завернуты. все так. авторГоспода, только довайте не будем спорить по поводу контрагентов,физиков и юриков.Если есть желание подискутировать по этому поводу, то в ERP и учетных система есть огромный топик по этому вопросу. Вроде бы Oracle и MSSQL обсуждаем... Давайте, а то оффтоп пошел сплошной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 14:22 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
softwarerРеальные структуры предъявляют еще большие требование - например, стоит помнить, что банки (в которых у контрагентов расчетные счета) имеют корр.счета в других банках, а сами банки при этом являются организациями и могут являться контрагентами. Впрочем, не понимаю, при чем здесь объектный подход - это вопрос грамотного или неграмотного проектирования в условиях той или иной конкретной задачи . ER-проектирование - достаточно "объектно". Полностью поддерживаю. авторВо всяком случае, наличие в 50 различных запросах фразы "[Юридическое лицо] JOIN [контрагент]" меня серьезно насторожит. Ну у меня физики и без вьюх - это одна таблица. А так - да, вьюхи нужны. Тока в MS SQL они странно работают, планы у них часто слетают. Может просто не знаю, как лечить, но пока что вьюхами особо не увлекаюсь. Роман ДынникЭто как? т.е. в контрагенте у вас будет 2-а поля одно из которых ссылается на ф/л, другое на ю/л? Это не правильно. Нет, это будет скорее всего, как я выше написал. авторЭто уже бизнеслогика. Правильно, это все бизнес-логика и архитектура БД. И никакого ООП. ShtockГоспода, только довайте не будем спорить по поводу контрагентов,физиков и юриков.Если есть желание подискутировать по этому поводу, то в ERP и учетных система есть огромный топик по этому вопросу. Вроде бы Oracle и MSSQL обсуждаем... Дык давно уж вопросы ушли вдаль от ответов. Или наоборот :) -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 14:27 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Можно и отдельный топик. Но это уже будет 3-й топик с ООП БД -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 14:28 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
tygraНу у меня физики и без вьюх - это одна таблица. А так - да, вьюхи нужны. В таких общих справочниках все равно оказывается куча мелочей - например, у физика есть документ, удостоверяющий личность, и типы этих документов, по идее - отдельный справочник. tygraТока в MS SQL они странно работают, планы у них часто слетают. Может просто не знаю, как лечить, но пока что вьюхами особо не увлекаюсь. Хм. Как-то так оказывается, что когда я на rsdn.ru цитирую местные утверждения про MS SQL - там просыпаются Sinclair или Merle и начинают говорить: "ну-ка, покажи, откуда ты это взял?" :) А что, у вьюхи в MS SQL есть какой-то фиксированный план? Немного странная концепция, имхо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 14:33 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
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" И я был прав! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 14:37 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторХотя вы все-же приведите, как бы сделали вы. тбл. сотрудник(id, должность)+fk к физ.лицо (1-к-1 наследование) по id для создания сотрудника 1) insert в контрагент 2) insert в физ.лицо 3) insert в сотрудник везде id будет один и тотже (1-к-1) это что бы ясно было. А реально бедет такая последовательность и вложенность вызовов: Код: plaintext 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 14:41 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
www.fun4me.narod.ruИ я был прав! Виноват - автоматом протянул ссылки в правильную сторону :) Я бы выдвинул к такой схеме другую претензию - можно завести контрагента, являющегося одновременно и физ-, и юр-лицом. Мало того, если действовать по частой для 1-1 схеме линковки по первичным ключам, это будет сделано автоматически - почти любой контрагент будет и физ., и юр.лицом (поскольку соответствующие записи будут в обеих таблицах). Такие схемы, как правило, делают, одновременно разделяя по "все положительные - физики, все отрицательные - юрики)" или по другому аналогичному критерию. Но, с моей точки зрения, подобные игры со значениями ПК крайне нежелательны. Их можно оставить для каких-то системных вопросов, но частные прикладные решения лучше делать "как надо". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 15:09 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторконтрагент будет и физ., и юр.лицом (поскольку соответствующие записи будут в обеих таблицах). да не будет контрагент и физ и юр лицом одновременно никогда! либо физ, либо юр! для физ будут записи: контрагент, физ для юр будут записи: контрагент, юр во вьюху физиков (физ JOIN контрагент) никогда не попадут записи из контрагент соответствующие юрикам. во вьюху юриков (юр JOIN контрагент) никогда не попадут записи из контрагент соответствующие физикам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 15:21 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Роман Дынникда не будет контрагент и физ и юр лицом одновременно никогда! либо физ, либо юр! для физ будут записи: контрагент, физ для юр будут записи: контрагент, юр За счет чего их не будет? За счет того, что Ваша программа (если Вы нигде не ошибетесь) сгенерит сначала id для контрагента, а потом использует его как id для физика либо юрика? К надежности этого.. я люблю вспоминать фразу Хайнлайна. - Знаешь, как мы называем женщин, полагающихся на календарный метод? Матерями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 15:27 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторЗа счет того, что Ваша программа (если Вы нигде не ошибетесь) сгенерит сначала id для контрагента, а потом использует его как id для физика либо юрика? К надежности этого.. я люблю вспоминать фразу Хайнлайна Не ошибется, т.к. все операции ч/з манипулирования данными ч/з хп. прямые инсерты в таблицы не допускаются. Манипулирование данными - это часть бизнес-логики. И с такими рассуждениями любую схему подвергнуть сомнению можно, что мешает ошибиться и поставить в поле-признаке юр/лица вместо "0" "1"? Этак мы вообще далеко сейчас уйдем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 15:37 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
автортбл. сотрудник(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 -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 15:59 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Роман ДынникНе ошибется, т.к. все операции ч/з манипулирования данными ч/з хп. прямые инсерты в таблицы не допускаются. Манипулирование данными - это часть бизнес-логики. Тогда - готовьте пеленки :) Роман ДынникИ с такими рассуждениями любую схему подвергнуть сомнению можно, что мешает ошибиться и поставить в поле-признаке юр/лица вместо "0" "1"? А какой идиот будет вводить такой признак? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 16:08 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторА какой идиот будет вводить такой признак? кое-кто вводит... 2Тигра авторВы не уверены, что я в состоянии написать N процедур для вставки во все таблицы Да уверен, уверен :)) просто я их не пишу, они у меня сами ГЕНЕРЯТСЯ (сами пишутся на основании ER-модели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 16:24 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Да я уж сам, по-старинке, руками :)) Тем более, что там есть еще кое-какая обработка, так что автоматически от силы 5% ХП можно сгенерить. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 16:29 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Роман ДынникДа уверен, уверен :)) просто я их не пишу, они у меня сами ГЕНЕРЯТСЯ (сами пишутся на основании ER-модели. 2tygra (задумчиво): пофлеймить на тему "нахрена такие процедуры нужны"? Или пожалеть нервы читателей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 16:30 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
А кстати, softwarer то сам как эту "задачку" решит? С юриками-физиками -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 16:31 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
tygraА кстати, softwarer то сам как эту "задачку" решит? С юриками-физиками Тогда уж постановку дайте :) А то основная причина флейма в таких темах - каждый говорит о задаче, которая у него когда-то была применительно к серверу, которым пользуется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 16:33 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторДа я уж сам, по-старинке, руками :)) Тем более, что там есть еще кое-какая обработка, так что автоматически от силы 5% ХП можно сгенерить. Ну вот... а у меня 70-80% Вопрос подхода... автор пофлеймить на тему "нахрена такие процедуры нужны"? Или пожалеть нервы читателей? Пофлейми, пофлейми, раз делать нечего. Все идут к тому чтобы сократить количество ручного коддинга, а ты еще флеймить собрался по поводу "надо или не надо". Этак у нас бы сейчас ни case-средств не было ни UML, и на коленках бы рисовали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 16:36 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Роман ДынникПофлейми, пофлейми, раз делать нечего. Все идут к тому чтобы сократить количество ручного коддинга, а ты еще флеймить собрался по поводу "надо или не надо". Этак у нас бы сейчас ни case-средств не было ни UML, и на коленках бы рисовали. Судя по этому заявлению, я верно оценил Ваш уровень. hint: такая практика не сокращает количество ручного кодирования, а только добавляет кучу малоосмысленного автосгенеренного кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 16:41 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
сплошные оскарбления пошли, что за народ такой неуважительный... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 16:44 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
автосгенерированный код вполне осмысленный получается, вручную я написал бы тоже самое. вот пример(сгенерировано все до запятой): Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 16:48 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
>> И что тут мало осмысленного? А почему процедура код ошибки не возвращает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 16:52 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Проверка if @@error<>0 GOTO UNDO после вызова процедуры не гарантирует успешного её выполнения. Да и в остальном - осмысленности не много, но это моё личное мнение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 16:58 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Вот пример для размышления: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Так что - срочно переписывайте весь свой автосгенерённый код ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:09 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
автор Да и в остальном - осмысленности не много, но это моё личное мнение. я что то не пойму в чем смысл вашей осмысленности? Если мне надо дополнительная бизнес-логика в процедуре я допишу ее. я просто показал что не трачу время на рутиную работу связанной с созданием сигнатуры и хп и типичных действий выполняемых хп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:09 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
>> я что то не пойму в чем смысл вашей осмысленности? У Вас процедура неправильная. Только и всего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:10 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
нда... Что вы сцепились из-за физиков и юриков? Ступайте в Проектирование и разбирайте там способы решения конкретной задачи. Без конкретной задачи не может быть и конкретного решения. Кастельно темы. Мне понравились вот такие новые фукнции в TSQL в Юконе. RANK () DENSE_RANK () ROW_NUMBER () NTILE () Интересно например сравнить с аналогичными функциями в Оракле, сравнить насколько удачно или неудачно они реализованы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:17 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
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) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:19 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:25 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Есть такая поговорка, то что нового появляется в DB2 переходит в стандарт SQL.... Шутка... RANK () DENSE_RANK () ROW_NUMBER () NTILE () По поводу этих функций все хорошо в меру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:29 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
softwarerА что, у вьюхи в MS SQL есть какой-то фиксированный план? Немного странная концепция, имхо...Не верьте, при построении плана запроса, view раскрываются, если только план view жестко не зафиксирован хинтами. tygraНу не знаю лично, есть ли план у вьюхи, но то, что если в выборках использовать вьюху, и не одну, то очень часто бывает, что вдруг слетают планы у ХП и именно из-за вьюхи, да и вообще непредсказуемо поведение. Ну это на достаточно сложных вьюхах, больше 2-х таблиц с некоторыми параметрами. На простых вроде ничего.Мне почему-то казалось, что Вы лучше разбираетесь в MS SQL. Как иногда говорят, с такими друзьями и врагов не надо :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:35 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Не, не будем флеймить! Тут по крайней мере!!! Давайте все же новый топик создадим и там по поводу юриков/физиков и написания ХП разберемся. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:37 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Один мой знакомый, очень мной уважаемый человек из Sybase говорил, что когда он допрашивает нового кандидата на каку-нить вакансию у него первый вопрос - когда и в каких случаях Sybase пересматривает планы запросов у ХП. Я не думаю что в этом плане MSSQL далеко ушел от своего родителя... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:42 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторНе верьте, при построении плана запроса, view раскрываются, если только план view жестко не зафиксирован хинтами. Я это понимаю, но факт есть факт, если сложная вьюха, то тормоза обеспечены. авторМне почему-то казалось, что Вы лучше разбираетесь в MS SQL. Как иногда говорят, с такими друзьями и врагов не надо :) На фиг враги - тут столько друзей :)) Я, если честно, во внутренностях выполнения запросов и т.д. не слишком то разбираюсь, так сказать в технической части. Но пока нет ни времени, ни охоты начинать - я не претендую на роль дба или гуру, просто есть некоторая часть опыта, позволяющая достаточно хорошо писать ХП. Остальное время уходит на разработку архитектуры (к счастью она не сильно зависит от знаний конкретной БД :)) + вообще много непрограммистской работы (не компьютерной, организационной так сказать). Но пока устраивает - меня не привлекает "маньячество" :) в программировании. Просто именно эта работа дает возможность зарабатывать деньги и ..... весело проводить время :)) -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:47 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
авторОдин мой знакомый, очень мной уважаемый человек из Sybase говорил, что когда он допрашивает нового кандидата на каку-нить вакансию у него первый вопрос - когда и в каких случаях Sybase пересматривает планы запросов у ХП. А если бы еще знать, почему они слетают (на MS SQL), тогда вообще было прекрасно :)) -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:49 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2 tygra Каждый вопрос содержит часть ответа) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:51 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
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 нигде ничего не написано. И в какой-то мере это недокументированное поведение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:53 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Такое ощущение, что сегодня пятница. Но календарь не врет - вторник, епрст... Хотя на улицу посмотришь, в монитор посмотришь - пятница блин, ну пятница...... А зря..... А завтра вот у нас корпоративное празднование НГ. Правда я не иду - не люблю я этого :) И в следующую среду улечу к себе домой на НГ аж до 10 числа. Эээхххххххххххххх -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 17:55 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Роман ДынникИ что тут мало осмысленного? Я бы спросил - что там осмысленного. Малоосмысленного - то, что если Вам верно подсказывают насчет недостатков этого кода (я не знаю T-SQL и ничего не скажу по этому поводу), то Вам придется устроить массовую перегенерацию/redeploy половины Вашей базы. В то время как достаточно было бы поменять пару строк в объекте типа "table inserter" (это, кстати, к объектному подходу). Если Ваша база уже стоит у клиента - Вам придется слать ему "патч" на десятки тысяч строк, в то время как достаточно бы было прислать одну dll-ку/class-файл. Я в общем почти уверен, что Вы ответите. И почти уверен, что в дискуссии с Вами сумею защитить даже позицию "джависта-все-на-аппсерверщика", которую считаю в корне неверной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 18:13 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
www.fun4me.narod.ru я извиняюсь, правильнее будет возвращать ошибку через return. пример некорректный был в плане управления транзакциями в #bad_generated_code1 и #bad_generated_code2. придется подпатчить немного генератор и перегенерить десяток хп. Фу... а ведь иначе бы пришлось руками всё править... SET XACT ABORT ON иногда много проблем решает. == оффтоп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 18:18 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2nkulikov а более точно можно? :) в частности, причем тут "все хорошо в меру"? PS. И потом, я привел всего лишь пример. В настоящий момент никакого отношения к Юкону беседа не имеет. PPS. Для любителей ООП - в Юконе можно и объекты (UDT) сохранять. Вы бы поисследовали эту тему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 18:20 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
AAronИнтересно например сравнить с аналогичными функциями в Оракле, сравнить насколько удачно или неудачно они реализованы. Хм. А как Вы представляете себе сравнение того, что реализовано в Оракле, с тем, что будет реализовано в (непонятно когда) выходящем Yukon. Или я отстал от жизни и он уже вышел? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 18:27 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
softwarerИли я отстал от жизни и он уже вышел?Yukon AKA MS SQL 2005... По календарю 2004 :) P.S. Вторую бету мучают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 18:32 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Роман Дынник Судя по Вашим высказываниям я вывел для себя примерно такую мысль "Мне с Тигрой давно пора бросать проектировать таблички и ХП, и переходить на ООП, потому что Вам так удобнее". Не обижайтесь, но смысл полностью таков. Далее еще раз не обижайтесь, но лично я вижу, что опыта проектирования БД и написания бизнес-логики на хранимых и триггерах у Вас маловато будет. Это не смертельно, но это не повод лично Вам выступать как просветителем "мрачных и морально устаревших" архитекторов БД. Далее могу сказать, что у меня на WatcomSQL (диалект ХП для ASA) написан движок, который по макетам может генерить ХП с параметрами, при запуске которых они создают в БД ХП, генерящие нужные действия. Это используется для генерации в моих личных целях HTTP-контентов и организации интранет-сайтов на базе ASA. Это же используется для генерации по макетам хранимых процедур и триггеров. Движок этот занимает ровно 12 небольших по обьему хранимых процедурок, которые расковыривают макет, выщемляют с него тело, определяют секции и параметры, описанные на XML, преобразуют ключевые слова в действия и генерят все в виде WatcomSQL скриптов. В итоге в моих БД 80% ХП тоже генериться автоматически. Я мог написать такой движок на ООП, но уверяю, меньше бы по размеру и трудоемкости написания он не стал, просто бы пришлось использовать при написании другие парадигмы. Далее мои и Ваши 80% автоматически сгенерированных процедур в БД не говорят о том, что мы с Вами круты, а вот Тигра нет. Это говорит только о том, что мы с Вами предпочитаем уводить DML операторы на уровень хранимых процедур и они вполне однотипны согласно определенным макетам. У меня во всяком случае в зависимости от типа сущности, который может обьединять в себя множество связанных таблиц и определенные аттрибуты могут автоматически генерится множество процедур по 7 различным макетам, все назначение которых - свести работу клиентского приложения с базой данных до примитивного уровня - получил в простом виде, изменил и вызвав ХП зафиксировал изменения в простом виде. Я уже молчу про множество автоматом генерящихся триггеров, которые в зависимости от определенной модели поведения занимаются различными проверками, вычислениями и другой полезной, но в принципе рутинной работой. Что имеем в заключение ? Имеем, что не средство определяет специалиста, а специалист определяет средство. Так же имеем, что чем шире у специалиста кругозор, тем больше решений в различных измерениях он может осознать и применить. Не надо думать, что Тигра или я в жизни не занимались ООП. Лично я потратил на это 7 лет своей жизни, написал добрую сотню визуальных/невизуальных компонент, несчетное кол-во классов, с десяток интрепретаторов и различных парсеров. Поэтому не надо лично мне заявлять, что мне пора отвыкать от таблиц и полей - это на самом деле не серьезно. Я знаю что такое ООП и успешно использую его по назначению каждый божий день :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 19:07 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
Гы - не удержусь - в конце концов с ООП я знаком с 1990 года, когда мне в руки попал славный добрый Turbo Pascal 5.5 и первое что я на нем сделал в качестве осмысливания ООП - это собственную навигационную базу данных :) Странно, что я с тех пор переменил свое мировозрение, не правда ли ? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2004, 19:11 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2 Роман Дынник >Не используют потому что не привыкли, потому что мыслят таблицами и записями, потому что надо время на изучение а его нет, потому что не везде целесообразно применять java-процедуры. Времени на изучение было больше 10 лет, это не объяснение. Когда в сайбейзе вводили поддержку джавы, очень многие сторонники ООП-а радостно потирали руки. Их-то учить не нужно. Но получился пшик, джава не прижилась, все продолжают использовать WatcomSQL. Думаю с другими SQL серверами та же ситуация. Есть более простое и правдоподобное объяснение: джаву в SQL серверах не используют потому что не удобно. Записи, поля, отношения гораздо удобнее объектов. ИМХО. По крайней мере для меня это так, теперь подтверждают и другие тоже. Я сам использую ООП иногда, в тех случаях, когда он что-то экономит, но экономит он далеко не всегда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 03:04 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
2softwarer Вообще, есть бетты, есть Express2005. Постоянно проводятся разные семинары. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 12:53 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
учитывая мой жестко критикуемый опыт в написании серверной логики, прошу здесь обсудить шаблон для вложенных хп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 15:23 |
|
||
|
Весомый плюс Юкон над ORACLE
|
|||
|---|---|---|---|
|
#18+
AAron2softwarer Вообще, есть бетты, есть Express2005. Постоянно проводятся разные семинары. Хм. Боюсь, я не представляю, как в таких условиях сравнивать реализацию. Насколько я понимаю, можно заявить, что "видимо, такие функции будут"; можно сказать, что "видимо, позволят меньше" либо "похоже, могут позволить и больше". Но собственно ключевые параметры работы - скорость и потребные ресурсы - сравнивать можно только у релизов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 16:49 |
|
||
|
|

start [/forum/topic.php?all=1&fid=35&tid=1553983]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
52ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
174ms |
get tp. blocked users: |
2ms |
| others: | 205ms |
| total: | 480ms |

| 0 / 0 |
