Пол года живу с «GAMING MOUSE x7» и бесконечно ей рад. Чёткий клик, мягкое нажатие, очень дискретный и лёгкий сроллинг, dpi можно переключать на ходу — что ещё надо для счастья?
Отличная офисная мышь :)) в StareConflict-е тоже не подводит, люблю её.
На работу такую же собираюсь купить.
При желании на три доп. кнопки можно какие то вещи повешать, но это рюшечки, и без них живётся хорошо.
Три доп копки, умножить ан 5 режимов, получаем 15 дополнительных функций, всё что хочешь можно забиндить, и не к чему из мышки делать вторую цифровую клавиатуру.
Решение любой задачи подразумевает выделение ресурсов — рабочего времени, были выделены сутки, в сутки я уложился.
В стратегическом плане конечно код будет в SVN / Mercurial храниться, опять же не раньше чем мне кто то выделит недельку на изучение этой темы применительно к СУБД ( PL/SQL Developer типа умеет работать с SVN, dbForge вообще с чем угодно, но что и как пока у нас ни кто не разбирался ).
Конечно у нас есть тестовый сервер, у нас даже есть сервер разработки, схема работы конечно такая: DEV — TEST — PROD.
Про "good practices" ни чего не слышал, мы в своей работе руководствуемся "best practices" :)
Oracle-based EPR из коробки с 20-летней историей — это Парус.
"Экземпляров" Паруса у нас кстати два, один клиент это завод с дискретным производством, другой клиент — продаёт услуги, у каждого своя специфика и за 10+ лет чуть более чем полностью переписанный функционал, так что от Паруса — там только название осталось.
Без понятия :)) считай эту сентенцию "старые версии объектов" авторской выдумкой, ради красного словца.
Может быть это не Oracle что то кэширует в сессии, а клиент ERP системы, и пока ERP клиент работает с устаревшими данными у пользователя происходят ошибки.
В представлении DBA_SOURCE есть типы объектов но у DBMS_METADATA.GET_DDL свои правила написания имён типов, и надо будет делать подмену 'PACKAGE' на 'PACKAGE_SPEC'
"alter session set current_schema=" — прикольно, это наверное и есть тот нюанс о котором знает "TOAD", но которого не знаю я.
"При этом, возможно, исходник возьмется из source ?" — без понятия, для себя я эту задачу решил и дополнительно тратить на неё время пока не хочется.
Из моего опыта, когда у тебя сваливается вся база, тысяч 15 процедур/пакетов/функций и ты пытаешься всё инвалидное откомпилить, да иногда приходиться убивать пользовательские сессии, а иногда без этого обходиться, да иногда пользователям надо перелогинится, а иногда без этого обходиться.
Мой опыт это год работы на Oracle 10g, за это время мы базу раз 10 роняли, раз на раз не приходиться, почему так — я не вникал.
Компиляция только на третьем шаге происходит, непосредственной подмены исходников — изменения записей таблицы SYS.SOURCE$ в алгоритме нет.
Собственно компиляция выполняется через "API" сервера, что бы сервер сам как ему надо все вопросы разрулил, и вообще был в курсе что у него исходники поменялись.
Пока не произошло компиляции ( CREATE OR REPLACE ) объекты себя ведут как всегда :)
После компиляции в некоторых сессиях могут вызываться старые версии объектов, поэтому если у пользователя что то "глючит", то ему просто надо перелогинится.
Не REGEXP_REPLACE — потому что я регулярными выражениями пользоваться не умею.
Не dbms_utility.COMPILE_SCHEMA — потому что это имело бы смысл при прямом изменении исходников в таблице SYS.SOURCE$, но мне не по себе от такого вмешательства в лоб.
Но конечно после того как все исходники будут обработаны — будет какое то количество INVALID объектов, поэтому как завершающий этап dbms_utility.COMPILE_SCHEMA — будет верным шагом, можно добавить в конец процедуры P_EXECUTE_CODE_UPDATE.
Временная таблица может быть записана на диск и проиндексирована, временная таблица существует даже после завершения выполнения блока кода.
Табличная переменная существует только в оперативной памяти и только внутри блока кода и не может быть проиндексирована.
Table variables does not have distribution statistics, theywill not trigger recompiles. Therefore, in many cases, the optimizer will build a query plan on the assumption that the table variable has no rows. For this reason, you should be cautious about using a table variable if you expect a larger number of rows (greater than 100).
что я упустил? у меня что количество колонок, что количество разделов в пределах десятка, мне надо тупо перебрать записи как элементы массива, зачем мне индексы? в чём я не прав?
В том что вы игнорируете описанные нюансы и настаиваете на единственно верном решении?
в нашем с вами обсуждении табличных переменных мы выяснили, что они бывают двух разных видов:
Disk-based
Memory-optimized
Теперь почитаем, что
Martin Smith
в своём коменте пишет:
Caveat
This answer discusses «classic» table variables introduced in SQL Server 2000. SQL Server 2014 in memory OLTP introduces Memory-Optimized Table Types. Table variable instances of those are different in many respects to the ones discuss
мой перевод «оптимизированные для памяти сильно отличаются от тех которые обсуждаются ниже, подробности по ссылке»,
перейдём по ссылку, и увидим:
The use of memory-optimized table variables has a number of advantages over traditional table variables:
The variables are truly in memory: they are guaranteed to never spill to disk
Мой перевод: «Эти переменных истинно в памяти, они гарантировано ни когда не скидываются на диск»
поэтому касательно моей комента к коду, за который вы меня мурыжите:
```sql
/* очищаем табличную переменную — освобождаем оперативную память */
```
можно сказать следующее:
если табличная переменная объявлена с типом имеющим «MEMORY_OPTIMIZED = ON» ( Memory-optimized ), то всё верно
если это old school table variable — Disk-based, то комментарий вводит в заблуждение
а теперь вернёмся к:
Не знаю, почему Вы в негативном ключе воспринимаете мои слова
Который касается вашей адекватности, я о себе пишу:
мой первый опыт «серьезной» работы с T-SQL
Но вы из контекста статьи вырываете отдельные части и относитесь к моим словам как к изречению гуру по T-SQL.
А потом понеслось «в Интернете кто то не прав» :))
Надо оно вам?
про tempdb ок, пусть пишется. не в этом суть, суть моих возражений была в том что табличная переменная всегда использует оперативную память. вы с этим не согласились :
Также немного смутили комментарии
можно поиграться с кодом :
-- Test registration in tempdb
SELECT COUNT(1) AS BEFOR FROM tempdb.sys.tables -- До объявления табличной переменной
GO
DECLARE @t1 TABLE (i INT)
SELECT COUNT(1) AS AFTER FROM tempdb.sys.tables -- После объявления табличной переменной
GO
SELECT COUNT(1) AS PAST FROM tempdb.sys.tables -- После блока кода с объявлением табличной переменной
-- Test Drop
SELECT COUNT(1) AS BEFOR FROM tempdb.sys.tables
GO
DECLARE @t2 TABLE (i INT)
SELECT COUNT(1) AS AFTER FROM tempdb.sys.tables
DROP TABLE @t2
GO
-- Test Trunc
SELECT COUNT(1) AS BEFOR FROM tempdb.sys.tables
GO
DECLARE @t3 TABLE (i INT)
SELECT COUNT(1) AS AFTER FROM tempdb.sys.tables
TRUNCATE TABLE @t3
GO
-- Test Delete
SELECT COUNT(1) AS BEFOR FROM tempdb.sys.tables
GO
DECLARE @t4 TABLE (i INT)
SELECT COUNT(1) AS AFTER FROM tempdb.sys.tables
DELETE @t4
GO
но этом нам даст только, то что "DELETE " это единственный способ удалить записи из табличной переменной.
If you are using SQL Server 2000 or higher, you can take advantage of the new TABLE variable type. These are similar to temporary tables except with more flexibility and they always stay in memory.
Like memory-optimized tables, memory-optimized table variables,
Must fit in memory and do not use disk resources.
Disk-based table variables exist in tempdb. Memory-optimized table variables exist in the user database (but they do not consume storage and are not recovered).
You cannot create a memory-optimized table variable using in-line syntax. Unlike disk-based table variables, you must create a type first.
оказывается табличные переменные бывают двух типов:
Disk-based
Memory-optimized
Memory-optimized должны быть объявлены с использованием пользовательского типа, пример:
CREATE TYPE [Sales].[SalesOrderDetailType_inmem] AS TABLE(
[ProductID] [int] NOT NULL,
[SpecialOfferID] [int] NOT NULL,
INDEX [IX_ProductID] HASH ([ProductID]) WITH ( BUCKET_COUNT = 8),
INDEX [IX_SpecialOfferID] NONCLUSTERED
)
WITH ( MEMORY_OPTIMIZED = ON )
у меня тоже 5.1.1.178. Я не знаю что мне в саппорт написать, закономерность установить не получается, писать "оно у меня падает" мне совесть не позволяет. я сам по техподдержке постоянно такие письма получаю :)
Не суть. Когда мне надо будет по работе писать много T-SQL кода, тогда и разберёмся.
по поводу бесплатности это как бы не аргумент, суровая российская реальность с вами не согласиться. Одна половина фишек из джентельменского набора, другой половиной я не пользуюсь. По поводу стабильности читайте мой комент
Не знаю какой хороший инструментарий для MS SQL, а для Oracle я пользуюсь PL/SQL Developer и TOAD, мне хватает, dbForge — только как форматировщик.
ЗЫ
ссылку на dbForge я даю в своём списке ссылок, вы до этого места видимо не дочитали?
у меня в коде есть комментарий который поясняет этот момент — с правильным использование курсоров в T-SQL не было времени разбираться, это согласитесь не на пол часа занятие.
Получить набор данных и спокойно с ним работать, не парясь ни за какие нюансы — на мой вкус это хорошая практика.
Кто то пишет супер оптимизированный код, кто то пишет много элементарного атомарного кода — мне ближе второй подход, с точки сопровождения это более удобный вариант.
я привожу ссылку Временные таблицы на статью про временные таблицы и табличные переменные, там написано, что табличная переменная живёт только в оперативке, на stack overflow пишут, что дропнуть табличную переменную нельзя, потому что её на жёстком диске нет, это как бы намекает что табличные переменные в tempdb не пишутся.
Кто из вас прав выясняйте без меня.
Мне не везёт с "dbForge Studio" у меня он падает в случайные моменты времени. Версия для MS SQL сервера на порядок стабильней версии для ORACLE SQL, но тем не менее тоже падает. конечно не проблема обратно открыть 10 окошек, но вымораживает.
Два простых примера — простейший рефакторинг — переименовать переменную — переименовывает во всём документе, до и после DECLARE этой переменной, то есть переименовывает там где заведомо делать этого не надо, при этом если вызвать переименование не на DECLARE, а просто в коде то как раз про DECLARE dbForge забудет.
Второе — а) генерация тестового набора данных( описано в статье ) — не генерил значение внешнего ключа, пришлось руками доделывать, б) при наборе записей больше 16 000 скрипт вставки данных превращался в венегрет, который конечно можно было распутать, но желания нет, в) Если задать генерацию справочника ( 10 записей ) и данных ( 10 000 записей ), то генерил данных ровно столько же сколько записей в справочнике, вместо 10 000 записей в таблице данных, всего 10.
"dbForge Studio" несомненно отличный продукт, если знать где раскиданы грабли.
Единственное что в нём отлично работает это форматировщик, у которого очень гибкие настройки, но и его порой заставить работать без бубна не получается.
на мой вкус dbForge — сырой продукт. и спорить с вами о вкусах я не буду.
Да в этом риск, что хакеры натворят делов, поэтому если система для внутреннего пользования и "не крупная" ( не больше 200 — 500 пользователей ) то доступ можно спокойно дать.
Пользователи всегда заинтересованы в скорейшем выполнении своей заявки, техподдержка без дела не сидит и любая самая пустячная заявка которая может подождать неделю — эту неделю ждать и будет. Поэтому если у пользователя есть способ своими руками сделать быстрее, то он сделает и часто пользователи не сообщают о системных ошибках которые исправляются за пару минут, потому что им дольше техподдержке объяснять в чём дело, чем исправить.
Если клиенты пользуются сервисом в качестве облачного, то такой способ хранения формул просто облегчает работу программиста — нет необходимости иметь отдельную хранимую процедуру под каждого пользователя.
При ошибке в формуле, отчёт не построиться или если будет адекватная обработка ошибок, то отдельные формулы не будут вычислены.
Основная идея — упрощение сопровождения.
Написать движок который строит произвольную таблицу не трудно, я подобный для веба уже писал .
Сегодня начал писать примитивную реализацию своей идеи, думаю к 10 марта допишу, будет время прикручу вывод отчёта на вебе.
По поводу "выражений"- можно много чего "накрутить", я просто поделился идеей. Для своих задач вы можете развить из этой идеи любой рабочий механизм.
Просто часто по работе изучая "best practices" я часто на Хабре находил отличные решения, поэтому почему бы не поделиться? Если кому то пригодиться я буду рад.
Отличная офисная мышь :)) в StareConflict-е тоже не подводит, люблю её.
На работу такую же собираюсь купить.
При желании на три доп. кнопки можно какие то вещи повешать, но это рюшечки, и без них живётся хорошо.
Три доп копки, умножить ан 5 режимов, получаем 15 дополнительных функций, всё что хочешь можно забиндить, и не к чему из мышки делать вторую цифровую клавиатуру.
В стратегическом плане конечно код будет в SVN / Mercurial храниться, опять же не раньше чем мне кто то выделит недельку на изучение этой темы применительно к СУБД ( PL/SQL Developer типа умеет работать с SVN, dbForge вообще с чем угодно, но что и как пока у нас ни кто не разбирался ).
Конечно у нас есть тестовый сервер, у нас даже есть сервер разработки, схема работы конечно такая: DEV — TEST — PROD.
Про "good practices" ни чего не слышал, мы в своей работе руководствуемся "best practices" :)
Oracle-based EPR из коробки с 20-летней историей — это Парус.
"Экземпляров" Паруса у нас кстати два, один клиент это завод с дискретным производством, другой клиент — продаёт услуги, у каждого своя специфика и за 10+ лет чуть более чем полностью переписанный функционал, так что от Паруса — там только название осталось.
Может быть это не Oracle что то кэширует в сессии, а клиент ERP системы, и пока ERP клиент работает с устаревшими данными у пользователя происходят ошибки.
"alter session set current_schema=" — прикольно, это наверное и есть тот нюанс о котором знает "TOAD", но которого не знаю я.
"При этом, возможно, исходник возьмется из source ?" — без понятия, для себя я эту задачу решил и дополнительно тратить на неё время пока не хочется.
Мой опыт это год работы на Oracle 10g, за это время мы базу раз 10 роняли, раз на раз не приходиться, почему так — я не вникал.
Собственно компиляция выполняется через "API" сервера, что бы сервер сам как ему надо все вопросы разрулил, и вообще был в курсе что у него исходники поменялись.
Пока не произошло компиляции ( CREATE OR REPLACE ) объекты себя ведут как всегда :)
После компиляции в некоторых сессиях могут вызываться старые версии объектов, поэтому если у пользователя что то "глючит", то ему просто надо перелогинится.
Не dbms_utility.COMPILE_SCHEMA — потому что это имело бы смысл при прямом изменении исходников в таблице SYS.SOURCE$, но мне не по себе от такого вмешательства в лоб.
Но конечно после того как все исходники будут обработаны — будет какое то количество INVALID объектов, поэтому как завершающий этап dbms_utility.COMPILE_SCHEMA — будет верным шагом, можно добавить в конец процедуры P_EXECUTE_CODE_UPDATE.
и т.п.
я пишу в статье:
MSDN пишет:
что я упустил? у меня что количество колонок, что количество разделов в пределах десятка, мне надо тупо перебрать записи как элементы массива, зачем мне индексы? в чём я не прав?
В том что вы игнорируете описанные нюансы и настаиваете на единственно верном решении?
в нашем с вами обсуждении табличных переменных мы выяснили, что они бывают двух разных видов:
Теперь почитаем, что
в своём коменте пишет:
мой перевод «оптимизированные для памяти сильно отличаются от тех которые обсуждаются ниже, подробности по ссылке»,
перейдём по ссылку, и увидим:
Мой перевод: «Эти переменных истинно в памяти, они гарантировано ни когда не скидываются на диск»
поэтому касательно моей комента к коду, за который вы меня мурыжите:
```sql
/* очищаем табличную переменную — освобождаем оперативную память */
```
можно сказать следующее:
а теперь вернёмся к:
Который касается вашей адекватности, я о себе пишу:
Но вы из контекста статьи вырываете отдельные части и относитесь к моим словам как к изречению гуру по T-SQL.
А потом понеслось «в Интернете кто то не прав» :))
Надо оно вам?
можно поиграться с кодом :
но этом нам даст только, то что "DELETE " это единственный способ удалить записи из табличной переменной.
из моего списка "литературы" идём по ссылке Temporary Tables
находим текст :
теперь курим MSDN
оказывается табличные переменные бывают двух типов:
Memory-optimized должны быть объявлены с использованием пользовательского типа, пример:
ок.
справедливость восстановлена?
Не суть. Когда мне надо будет по работе писать много T-SQL кода, тогда и разберёмся.
Не знаю какой хороший инструментарий для MS SQL, а для Oracle я пользуюсь PL/SQL Developer и TOAD, мне хватает, dbForge — только как форматировщик.
ЗЫ
ссылку на dbForge я даю в своём списке ссылок, вы до этого места видимо не дочитали?
у меня в коде есть комментарий который поясняет этот момент — с правильным использование курсоров в T-SQL не было времени разбираться, это согласитесь не на пол часа занятие.
Получить набор данных и спокойно с ним работать, не парясь ни за какие нюансы — на мой вкус это хорошая практика.
Кто то пишет супер оптимизированный код, кто то пишет много элементарного атомарного кода — мне ближе второй подход, с точки сопровождения это более удобный вариант.
я привожу ссылку Временные таблицы на статью про временные таблицы и табличные переменные, там написано, что табличная переменная живёт только в оперативке, на stack overflow пишут, что дропнуть табличную переменную нельзя, потому что её на жёстком диске нет, это как бы намекает что табличные переменные в tempdb не пишутся.
Кто из вас прав выясняйте без меня.
Два простых примера — простейший рефакторинг — переименовать переменную — переименовывает во всём документе, до и после DECLARE этой переменной, то есть переименовывает там где заведомо делать этого не надо, при этом если вызвать переименование не на DECLARE, а просто в коде то как раз про DECLARE dbForge забудет.
Второе — а) генерация тестового набора данных( описано в статье ) — не генерил значение внешнего ключа, пришлось руками доделывать, б) при наборе записей больше 16 000 скрипт вставки данных превращался в венегрет, который конечно можно было распутать, но желания нет, в) Если задать генерацию справочника ( 10 записей ) и данных ( 10 000 записей ), то генерил данных ровно столько же сколько записей в справочнике, вместо 10 000 записей в таблице данных, всего 10.
"dbForge Studio" несомненно отличный продукт, если знать где раскиданы грабли.
Единственное что в нём отлично работает это форматировщик, у которого очень гибкие настройки, но и его порой заставить работать без бубна не получается.
на мой вкус dbForge — сырой продукт. и спорить с вами о вкусах я не буду.
Пользователи всегда заинтересованы в скорейшем выполнении своей заявки, техподдержка без дела не сидит и любая самая пустячная заявка которая может подождать неделю — эту неделю ждать и будет. Поэтому если у пользователя есть способ своими руками сделать быстрее, то он сделает и часто пользователи не сообщают о системных ошибках которые исправляются за пару минут, потому что им дольше техподдержке объяснять в чём дело, чем исправить.
Если клиенты пользуются сервисом в качестве облачного, то такой способ хранения формул просто облегчает работу программиста — нет необходимости иметь отдельную хранимую процедуру под каждого пользователя.
При ошибке в формуле, отчёт не построиться или если будет адекватная обработка ошибок, то отдельные формулы не будут вычислены.
Основная идея — упрощение сопровождения.
Написать движок который строит произвольную таблицу не трудно, я подобный для веба уже писал .
Сегодня начал писать примитивную реализацию своей идеи, думаю к 10 марта допишу, будет время прикручу вывод отчёта на вебе.
По поводу "выражений"- можно много чего "накрутить", я просто поделился идеей. Для своих задач вы можете развить из этой идеи любой рабочий механизм.
Просто часто по работе изучая "best practices" я часто на Хабре находил отличные решения, поэтому почему бы не поделиться? Если кому то пригодиться я буду рад.