|
|
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
разрабатываю приложения и на данном этапе меня терзают смутные сомнения на сегодня в базе 131 табличка - и это только начало для обслуживания каждой таблички существует как-минимум 4 CRUD-sp уже сейчас сложно ориетироваться в такой системе, а что же будет дальше? Это правильный путь разработки? у всех так или только я один такой дурак!? :) Поделитесь опытом пожалуйста! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2009, 19:04 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
sp на сегодня в базе 131 табличка - и это только началоЯ работал с базами по 5000 таблиц. Дурное дело нехитрое sp для обслуживания каждой таблички существует как-минимум 4 CRUD-sp Хорошие правила наименования вам помогут. sp уже сейчас сложно ориетироваться в такой системе, а что же будет дальше?Приличные средства разработки должны фильтровать списки объектов до приемлимых величин sp у всех так или только я один такой дурак!? :)Риальные пацаны делают EAV с тремя таблицами sp Поделитесь опытом пожалуйста!Один из подходов засунуть все lookup таблицы типа id, description в одну большую id, description, type. Рекомендую просмотреть полемику на предмет взвешивания достоинств и недостатков подхода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2009, 19:33 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
spразрабатываю приложения и на данном этапе меня терзают смутные сомнения на сегодня в базе 131 табличка - и это только начало для обслуживания каждой таблички существует как-минимум 4 CRUD-sp На самом деле - это вопрос религии, поэтому иногда провоцирует "крестовые походы" (на RSDN'е вообще часто по этому поводу спорят). Поступить можно по-разному: 1. Оставить все как есть, просто ввести некую систему стандартного именования CRUD-процедур (как предложили выше). 2. Вносить изменения напрямую в таблицы БД (возможны проблемы с безопасностью, хотя все зависит от требований к системе). 3. Использовать обновляемые представления , если твоя СУБД их поддерживает (CRUD-процедуры превратятся в триггеры представлений). У всех вариантов свои плюсы и минусы. Во что веруешь, то и используй.... Только одно замечание: почему CRUD-процедур 4? Ты SELECT тоже в отдельную процедуру запихиваешь? Уверен, что тебе ВСЕГДА понадобиться тянуть на клиента ВСЕ столбцы из таблиц? Может команду SELECT лучше с клиента слать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2009, 12:23 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
Я именую типа Checks - чеки CheckMakers CheckMakersCompanies Companies CompanyDetails CompanyAddresses CompanyEmployees Employees EmployeeRights EmployeeWorkHours EmployeeWorkHoursOfficeManagers Ну и так впринципе могу наверное до бесконечности их плодить.. за 1000 штук уже было idшки и fkшки всегда EmployeeID, EmployeeRightID. гляда на имя таблицы или fk я уже сразу знаю куда он ссылается и как это правильно написать. Ну и если меня там интересует что-то по деталям компании то знаю что табличка начинается с Company а потом идет скорее всего Detail ну и тд. Не знаю зачем нужно 4 процедуры на таблицу.. У меня процедуры как правильно бизнес логику делают. Типа sp_EmployeeFire(EmployeeID) или sp_genReportsWorkhoursEmployee ну и она там уже разбирается что нужно сделать для увольнения/генерации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2009, 15:27 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
Хранить скрипты только в файлах, сложенных в логично названных папках. Работать только со скриптами. Версионный контроль. У нас ок. 800скриптов = более 2тыс. ХП. 340таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2009, 16:06 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
LSVХранить скрипты только в файлах, сложенных в логично названных папках. Работать только со скриптами. Версионный контроль. У нас ок. 800скриптов = более 2тыс. ХП. 340таблиц. А что делают эти 2000 ХП? Основная масса из них? Что делать если накатили эти версионные скрипты на продакшн и там что-то таки сдохло? любопытно просто ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2009, 16:19 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
stomsky Может команду SELECT лучше с клиента слать?А вот это еще один не менее религиозный вопрос. Кстати тут же и ответ, что может лежать в тысячах процедур. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2009, 17:10 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
Кстати, по поводу кол. таблиц и процедур :) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Это на тему "сложно ориентироваться" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2009, 17:48 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
EsuНе знаю зачем нужно 4 процедуры на таблицу.. У меня процедуры как правильно бизнес логику делают. Типа sp_EmployeeFire(EmployeeID) или sp_genReportsWorkhoursEmployee ну и она там уже разбирается что нужно сделать для увольнения/генерации. 4 sp-ши - создание, удаление. модификация, изменения чтатуса, печати, поиска и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2009, 20:50 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
stomskyТолько одно замечание: почему CRUD-процедур 4? Ты SELECT тоже в отдельную процедуру запихиваешь? Уверен, что тебе ВСЕГДА понадобиться тянуть на клиента ВСЕ столбцы из таблиц? Может команду SELECT лучше с клиента слать? Да, на выборку у меня тоже своя спшка -потому как для какждой роли объект к юзеру толи передом толи задом ))) и где это учитывать как не в селест-спшке?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2009, 20:52 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55Кстати, по поводу кол. таблиц и процедур :) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Это на тему "сложно ориентироваться" зачем же так грубо? моглиб сказать что около того....:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2009, 00:28 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
EsuА что делают эти 2000 ХП? Основная масса из них? Что делать если накатили эти версионные скрипты на продакшн и там что-то таки сдохло? любопытно простоВся работа - исключительно через ХП. Поэтому на каждый "некий список" с десяток ХП: удаление, обновление, добавление, чтение, смена владельца, поиск, ну и т.д. Долго рассказывать. Что значит сдохло ? Заработало не так ? Корректируется и снова накатывается скрипт. Есть встроенная система информирования разработчиков об ошибках. Критичные доработки тестируются на запасной базе. Иногда требуется перекомпиляция проекта. ЗЫ: Корпоративная система: торговля, кадры, автотранспорт, учет затрат, проектных работ и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2009, 10:52 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
SERG1257stomsky Может команду SELECT лучше с клиента слать?А вот это еще один не менее религиозный вопрос. Кстати тут же и ответ, что может лежать в тысячах процедур. Согласен, просто я хотел услышать обоснование. Может есть что-то такое, что для меня не очевидно... spДа, на выборку у меня тоже своя спшка -потому как для какждой роли объект к юзеру толи передом толи задом ))) и где это учитывать как не в селест-спшке?? Я не очень понял, что в данном случае понимается под словом "объект"? Все отдельные сущности некоторого типа (т.е. все строки, хранящиеся в таблице, для которой заведена SELECT-овая хранимка) или отдельные сущности этого типа (т.е. отдельные строки таблицы)? Если первое, то почему не реализовать безопасность средствами MSSQL (т.е. некоторым ролям пользователей разрешить SELECT из таблицы, а некоторым - запретить)? Если второе (т.е. речь идет о Row Level Security), то можно и во View-шке это реализовать... Хотя, если если у тебя нет таблиц с огромным количеством столбцов, если нет столбцов типа image или text, если твои SELECT запросы не будут возвращать миллионы строк на клиента, то на тему SELECT-овой хранимки можешь вообще забить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2009, 19:05 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
stomsky Я не очень понял, что в данном случае понимается под словом "объект"? Все отдельные сущности некоторого типа (т.е. все строки, хранящиеся в таблице, для которой заведена SELECT-овая хранимка) или отдельные сущности этого типа (т.е. отдельные строки таблицы)? второе stomsky Если первое, то почему не реализовать безопасность средствами MSSQL (т.е. некоторым ролям пользователей разрешить SELECT из таблицы, а некоторым - запретить)? Если второе (т.е. речь идет о Row Level Security), то можно и во View-шке это реализовать... для каждой роли необходимо по-разному преподносить данные, где роль пожирнее и побагаче - с рюшечками, а где работяга - серые стены и каменное сидение (это в демократиях так принято) и роли у нас используются не серверные а функциональные, поэтому и права раздаются в бд при помощи метаданных stomsky Хотя, если если у тебя нет таблиц с огромным количеством столбцов, если нет столбцов типа image или text, если твои SELECT запросы не будут возвращать миллионы строк на клиента, то на тему SELECT-овой хранимки можешь вообще забить... тут не понял о чем Вы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2009, 04:13 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
spдля каждой роли необходимо по-разному преподносить данные, где роль пожирнее и побагаче - с рюшечками, а где работяга - серые стены и каменное сидение (это в демократиях так принято) и роли у нас используются не серверные а функциональные, поэтому и права раздаются в бд при помощи метаданных А где тут противопоказание для использования View'шек? spstomsky Хотя, если если у тебя нет таблиц с огромным количеством столбцов, если нет столбцов типа image или text, если твои SELECT запросы не будут возвращать миллионы строк на клиента, то на тему SELECT-овой хранимки можешь вообще забить... тут не понял о чем Вы Ну как... прикинь: у тебя есть таблица с парой сотен столбцов. Тебе нужно сделать SELECT который возвращает таблицу всего из 3-х (трех) столбцов (остальные 197 столбцов в данном конкретном случае тебе НЕ нужны). Если у тебя всего одна SELECT'овая хранимка для данной таблицы, которая ВСЕГДА возвращает один и тот же набор столбцов (скорее всего все, т.к. в разных частях программы могут понадобиться разные столбцы в разных комбинациях), то и для данного конкретного SELECT'а ты вытянешь данные всех столбцов, а не только 3-х которые тебе на самом деле требуются. Лишние данные будут передаваться. Если строк в результате SELECT'а возвращается, ну скажем, десяток, то это еще ничего. А если пара сотен тысяч? Ты дофига ненужной информации будешь выводить за пределы базы данных. А это дело накладное! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2009, 13:56 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
stomsky А где тут противопоказание для использования View'шек?Например требование логировать SELECT stomsky Тебе нужно сделать SELECT который возвращает таблицу всего из 3-х (трех) столбцов (остальные 197 столбцов в данном конкретном случае тебе НЕ нужны).Кто мешает написать ДРУГУЮ процедуру с ограниченным набором столбцов. Еще раз повторюсь это вопрос религиозный, подход имеет свои достоинства и недостатки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2009, 17:31 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
SERG1257stomsky А где тут противопоказание для использования View'шек?Например требование логировать SELECT А-а-а-а... ну если есть такое требование, то мне возразить нечего... Лучше хранимки ничего предложить не могу... Хотя вопрос возникает: если пользователю даны права на SELECT из таблицы, то зачем контролировать что именно, когда и сколько раз выбиралось? Если пользователь имеет право видеть данные, значит надо считать, что он их уже видел! Если ему не положено - не давайте права и все тут! Всякие INSERT'ы, UPDATE'ы, DELETE'ы может и надо логировать, чтобы потом найти кто внес в данные таблицы "непоправимые улучшения". А для выборки-то это зачем? По-моему так... Хотя я не безопасник... SERG1257stomsky Тебе нужно сделать SELECT который возвращает таблицу всего из 3-х (трех) столбцов (остальные 197 столбцов в данном конкретном случае тебе НЕ нужны).Кто мешает написать ДРУГУЮ процедуру с ограниченным набором столбцов. Автор топика написал про 4 хранимки, одна из которых SELECT'овая. Если под каждый существенно различающийся SELECT свою хранимку завести, то мой пример, конечно, не актуален. SERG1257Еще раз повторюсь это вопрос религиозный, подход имеет свои достоинства и недостатки. Я о том же. Лично я пока сторонник отправки с клиента именно SELECT'а, а не вызова хранимок. Но если есть требование топа логирования SELECT'ов (нужно это или нет - вопрос другой, заказчику виднее), то не возражаю против хранимок. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2009, 08:19 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
SERG1257stomsky А где тут противопоказание для использования View'шек?Например требование логировать SELECTэкзотическое требование, в каких случаях оно может возникнуть, интересно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2009, 11:56 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
egorychэкзотическое требование, в каких случаях оно может возникнуть, интересно? это не экзотическое требование, а обыденный аттрибут любой нормальной системы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2009, 00:03 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
spegorychэкзотическое требование, в каких случаях оно может возникнуть, интересно?это не экзотическое требование, а обыденный аттрибут любой нормальной системыда бог с вами, зачем селекты-то логировать? раскройте поподробнее что-ли тему ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2009, 00:11 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
egorychspegorychэкзотическое требование, в каких случаях оно может возникнуть, интересно?это не экзотическое требование, а обыденный аттрибут любой нормальной системыда бог с вами, зачем селекты-то логировать? раскройте поподробнее что-ли тему "Иметь возможность логировать" и "логировать" - разные вещи. Думаю, налицо типичный пример аудита: в возможности логировать предусматривается опциональное включение/выключение в зависимости от указанных фильтров: "для такого-то пользователя/группы", "для такого-то модуля", "в период времени с .. по ..". И поводов много, вплоть до банального "что ж это за запрос так грузит систему?!"... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2009, 11:27 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
АнатоЛой, вы же должны понимать, что это не объяснение. Писать кучу кода и просаживать производительность базы надо по существенным поводам, а не для реализации возможности, ценность наличия которой до сих пор не ясна. >> поводов много, вплоть до банального "что ж это за запрос так грузит систему?!"... - для решения конкретно этой задачи существуют профайлеры, которые с ней справляются лучше, чем самодельные велосипеды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2009, 11:44 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
spэто не экзотическое требование, а обыденный аттрибут любой нормальной системы Да Бог с вами. Возможно, это атрибут любой системы, которую делаете именно вы, но это же не повод для таких странных обобщений. Или каждый старается свою болезни назвать нормой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2009, 15:22 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
egorychАнатоЛой, вы же должны понимать, что это не объяснение. Писать кучу кода и просаживать производительность базы надо по существенным поводам, а не для реализации возможности, ценность наличия которой до сих пор не ясна. >> поводов много, вплоть до банального "что ж это за запрос так грузит систему?!"... - для решения конкретно этой задачи существуют профайлеры, которые с ней справляются лучше, чем самодельные велосипеды. Я не говорил, что требование нужно реализовывать самому, это требование может предъявляться к системе. С помощью каких технологий и инструментов система её закрывает - это уже реализация. Для примера: не для всякой СУБД, которую может использовать система, и не со всеми нюансами требования могут справиться существующие профайлеры. А уж как собственная реализация будет сделана, и на сколько она будет грузить систему - от кривости ручек зависит... Упомянутый профайлер не грузит систему? Почему собственная реализация обязана делать свою работу хуже? А слабо под "существующим профайлером" пару сотен пользователей запустить, чтобы понять, какая редиска в 3 часа ночи сервак нагрузила? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2009, 20:40 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
spegorychэкзотическое требование, в каких случаях оно может возникнуть, интересно? это не экзотическое требование, а обыденный аттрибут любой нормальной системы :) какая нормальная система не знает то, что у нее может запросить конкретный пользователь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 00:01 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
iscrafm это не экзотическое требование, а обыденный аттрибут любой нормальной системы :) какая нормальная система не знает то, что у нее может запросить конкретный пользователь?[/quot] Конечно знает, но ей надо знать, а смотрел ли и когда, жели бы вы работали в более или менее серьезной конторе - там бы вы с этим столкнулись - т.к. наличие ауидита - это аттрибут любой мало-мальски серьезной системы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 00:51 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
spей надо знать, а смотрел ли и когда, жели бы вы работали в более или менее серьезной конторе - там бы вы с этим столкнулись - т.к. наличие ауидита - это аттрибут любой мало-мальски серьезной системы в "серьезных конторах" не работал, но что-то мне подсказывает, что полезно знать кто, что и когда сделал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 00:58 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
spКонечно знает, но ей надо знать, а смотрел ли и когда, жели бы вы работали в более или менее серьезной конторе - там бы вы с этим столкнулись - т.к. наличие ауидита - это аттрибут любой мало-мальски серьезной системы Наличие аудита -- да, но аудит SELECT -- это экзотика. Причём вредная, так как сильно бьёт по производительности. Аудируют модификации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 08:35 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
mir_unregistered Наличие аудита -- да, но аудит SELECT -- это экзотика. Причём вредная, так как сильно бьёт по производительности. Аудируют модификации. Не знаю насчет экзотики, но в Oracle например есть. Насчет производительности - так за все надо платить. Тем паче, что аудит, как правило, используют не постоянно, а включают на достаточно короткое время в случае появления каких-то подозрений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 10:51 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
sp для обслуживания каждой таблички существует как-минимум 4 CRUD-sp уже сейчас сложно ориетироваться в такой системе, а что же будет дальше? Это правильный путь разработки? Был следующий опыт: Дабы не мучиться с поддержкой CRUD-хп на первых циклах разработки, встал вопрос "как в последствии можно наиболее быстро и безболезненно перейти с прямых операций с таблицами на CRUD-хп". Во общем то все довольно логично: CRUD-хп для всех таблиц практически идентичны, так почему бы их не сгенерить впоследствии, когда система выйдет из разряда прототипа? Взял NHibernate в качестве ORM. С маппингом не все так просто оказалось. Дело в том, что если в маппинге используется inheritance, то если в последствии потребуется использование sql-insert/update/delete, то NH будет выполнять вызов этих действий для каждого уровня иерархии. Но тут вопрос к реализации CRUD - идет ли вызов create предка внутри create потомка. Если вызов плоский - то проблем нет, если нет - необходимо добиться от NH единственного вызова create потомка. Во общем, по сути получалось два разных маппинга в случае прямых insert-ов и insert-ов через CRUD. Решил шалонизировать маппинг через XSLT. Т.е. маппинг у меня в конечном итоге генерился и включался в ресурсы при компиляции (msbuild post build events). В одном случае маппинг генерился для иерархии таблиц, в случае CRUD маппинг генерился на view, представляющий собой join иерархии классов. Написал unit tests, сгенерил и подставил маппинг для случая без CRUD, прогнал тесты. Потом на каком то этапе переходим на CRUD хп: сгенерили CRUD-хп. сгенерили NH-маппинг для CRUD, подставили его. прогнали unit tests. ... В конце концов можно добиться того, что при развертывании выбирать будет ли система работать через CRUD или через прямые операции с таблицами. Требования бывают разные. С CRUD-ом, например, достаточно сложно обеспечить полномасштабное использование кеша NH. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 11:46 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55включают на достаточно короткое время в случае появления каких-то подозрений подозрение на счет того, смотрел ли человек на экран или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 11:51 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
аудит можно сделать и на уровне app-сервера/среднего слоя. это вопрос требований. в MSSQL, select и прочую "экзотику" можно, например, логировать через профайлер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 11:53 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
АнатоЛойЯ не говорил, что требование нужно реализовывать самому, это требование может предъявляться к системе. С помощью каких технологий и инструментов система её закрывает - это уже реализация.мы и говорим о реализации. Конкретно, о реализации логирования вызовов оператора SELECT посредством хранимых процедур, помните? В какую конкретно систему такие возможности встроены, чтобы их не надо было реализовывать самому, не подскажете? АнатоЛойА слабо под "существующим профайлером" пару сотен пользователей запустить, чтобы понять, какая редиска в 3 часа ночи сервак нагрузила?тот факт, что таблица лога в данном случае сто пудов станет узким местом не учитываем, да? сколько раз пара сотен пользователей обновит у себя оперативное представление? и каждый раз мы это будем логировать? сумасшествие какое то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 12:11 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
iscrafmtru55включают на достаточно короткое время в случае появления каких-то подозрений подозрение на счет того, смотрел ли человек на экран или нет? Не на экран, а на данные... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 12:23 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55iscrafmtru55включают на достаточно короткое время в случае появления каких-то подозрений подозрение на счет того, смотрел ли человек на экран или нет? Не на экран, а на данные...и зачем это надо знать? хоть кто-нить может вразумительно ответить, а не на уровне общих рассуждений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 12:29 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
egorych и зачем это надо знать? хоть кто-нить может вразумительно ответить, а не на уровне общих рассуждений Информация бывает открытая и закрытая (по крайней мере, для части публики). Способы скрыть инфу от "ненужных" глаз бывают разные, в том числе и аудит (в смысле логирования)... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 12:51 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55, если в системе у каждого клиента есть строго определенные полномочия на доступ к информации, то в чем полезность логирования селектов тоже не понятна. Логирование действий не обсуждается... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 12:55 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55Информация бывает открытая и закрытая (по крайней мере, для части публики). Способы скрыть инфу от "ненужных" глаз бывают разные, в том числе и аудит (в смысле логирования)...вы издеваетесь? как логирование может чего-то скрыть? логирование фиксирует факт совершения операции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 13:27 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
iscrafm если в системе у каждого клиента есть строго определенные полномочия на доступ к информации, то в чем полезность логирования селектов тоже не понятна. Логирование действий не обсуждается... Для чего ставят видеокамеры в охраняемых местах, допустим, у сейфа с документами? Хотя вполне возможно, что есть охрана, которая кого не надо к сейфу не пустит. Дополнительная степень защиты от несанкционированного доступа. Если не смогли предотвратить, то сможем хотя бы поймать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 13:35 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55Для чего ставят видеокамеры в охраняемых местах, допустим, у сейфа с документами? Хотя вполне возможно, что есть охрана, которая кого не надо к сейфу не пустит. Дополнительная степень защиты от несанкционированного доступа. Если не смогли предотвратить, то сможем хотя бы поймать...Вы точно издеваетесь. К вашему сведению, есть такая вещь как раздача прав доступа, в т.ч. на просмотр данных. Если не хотят, чтобы человек видел какие-то поля, ему их запрещают видеть. В вашей аналогии это будет так. Вместо того, чтобы выдать ключи от шкафа только доверенным людям, вы сначала раздаёте ключи всем подряд (или вовсе не закрываете дверцу), а потом через видеокамеру пытаетесь поймать тех, кто в шкаф смотрит, не имея на это оснований. Бред. Полный бред. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 13:57 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
mir_unregistered Вы точно издеваетесь. К вашему сведению, есть такая вещь как раздача прав доступа, в т.ч. на просмотр данных. Если не хотят, чтобы человек видел какие-то поля, ему их запрещают видеть. Да ну? А на кой тогда имеется возможность следить за изменениями данных, если их изменяют только те, кто имеет право? mir_unregistered В вашей аналогии это будет так. Вместо того, чтобы выдать ключи от шкафа только доверенным людям, вы сначала раздаёте ключи всем подряд (или вовсе не закрываете дверцу), а потом через видеокамеру пытаетесь поймать тех, кто в шкаф смотрит, не имея на это оснований. Как известно, любая защита обходится за конечное время. В противном случае такого понятия, как кража информации просто не существовало бы. mir_unregistered Бред. Полный бред. Я уже упомянул о том, что в Oracle реализована возможность следить за селектами. Подозреваю, что и в других СУБД тоже (во всяком случае в некоторых). Значит, либо бредят куча производителей этих баз, либо кто-то другой... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 14:16 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55mir_unregistered Вы точно издеваетесь. К вашему сведению, есть такая вещь как раздача прав доступа, в т.ч. на просмотр данных. Если не хотят, чтобы человек видел какие-то поля, ему их запрещают видеть. Да ну? А на кой тогда имеется возможность следить за изменениями данных, если их изменяют только те, кто имеет право?вы правда не понимаете, зачем следят за обновлениями данных? Потому что даже те, кто имеет право на обновление, могут внести некорректные данные. Как эта ситуация отображается на логирование выборок? tru55Я уже упомянул о том, что в Oracle реализована возможность следить за селектами. следить или логировать? разница ощутимая ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 14:48 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
egorychtru55mir_unregistered Вы точно издеваетесь. К вашему сведению, есть такая вещь как раздача прав доступа, в т.ч. на просмотр данных. Если не хотят, чтобы человек видел какие-то поля, ему их запрещают видеть. Да ну? А на кой тогда имеется возможность следить за изменениями данных, если их изменяют только те, кто имеет право?вы правда не понимаете, зачем следят за обновлениями данных? Потому что даже те, кто имеет право на обновление, могут внести некорректные данные. Как эта ситуация отображается на логирование выборок? Если данные изменены ошибочно, то причем тут логирование (если опять же, не брать в расчет "разбор полетов")? Для возврата к прежнему состоянию (опять же на примере Oracle) есть: 1. rollback 2. разные формы flashback 3. LogMiner 4. восстановление из backup egorych tru55Я уже упомянул о том, что в Oracle реализована возможность следить за селектами. следить или логировать? разница ощутимая Под следить я имел ввиду логировать, ибо следить - это в настоящем времени, а логирование позволяет разбираться и в прошедшем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 15:01 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55Если данные изменены ошибочно, то причем тут логирование (если опять же, не брать в расчет "разбор полетов")? логируют как раз для разбора полётов, это же очевидно. tru55egorych tru55Я уже упомянул о том, что в Oracle реализована возможность следить за селектами. следить или логировать? разница ощутимая Под следить я имел ввиду логировать, ибо следить - это в настоящем времени, а логирование позволяет разбираться и в прошедшем.чего можно разобрать, если мы знаем, что пользователь Х 197 раз в день обновил у себя в клиентской программе грид с данными? зачем нужны эти сведения? что полезного мы можем из них почерпнуть? и стоит ли ради их получения увеличивать время разработки и просаживать производительность? - вот вопросы, ответы на которые хочется получить, а не общие рассуждения, что "мол, надо" и "мол, сделано". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 15:21 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
egorychtru55Если данные изменены ошибочно, то причем тут логирование (если опять же, не брать в расчет "разбор полетов")? логируют как раз для разбора полётов, это же очевидно. Неочевидно. Например когда-то имел дело с системой (разрабатывал в том числе), в которой на критические таблицы были навешаны триггера, переносившие при UPDATE/DELETE предыдущую версию данных в исторические таблицы. Эти записи использовались как для разбора полетов, так и для упрощения восстановления предыдущего состояния. К слову сказать, в Oracle 11 реализована похожая вещь на системном уровне. egorych чего можно разобрать, если мы знаем, что пользователь Х 197 раз в день обновил у себя в клиентской программе грид с данными? зачем нужны эти сведения? что полезного мы можем из них почерпнуть? и стоит ли ради их получения увеличивать время разработки и просаживать производительность? - вот вопросы, ответы на которые хочется получить, а не общие рассуждения, что "мол, надо" и "мол, сделано". 1. здесь рассматривается достаточно узкий случай. Как правило, к базе можно доступиться не только через разработанную клиентскую программу, но и другими инструментами 2. для чего - я уже сказал выше - доп. уровень защиты 3. по поводу производительности: - поскольку это логирование включается периодически, то влияние не столь велико - есть куча не сильно нагруженных систем, на которых эта доп. добавка просто будет незаметна - за любой сервис надо платить. Скажем, в Oracle с 10 версии по умолчанию работает постоянный сбор статистики работы, что можно использовать для мониторинга производительности базы, отлова "тяжелого" SQL и проч. Естественно, это доп. нагрузка на сервер. Поэтому, если производительность критична, то эту систему отключают, теряя при этом упомянутые удобства 4. "сделано" - это не общие рассуждения. Если люди реализовывали это на уровне СУБД (Oracle), значит подобная вещь имеет спрос ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 15:40 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55Например когда-то имел дело с системой (разрабатывал в том числе), в которой на критические таблицы были навешаны триггера, переносившие при UPDATE/DELETE предыдущую версию данных в исторические таблицы. Эти записи использовались как для разбора полетов, так и для упрощения восстановления предыдущего состояния. это одно и то же )) решение о восстановлении предыдущего состояния принимается по результатам разбора )) tru55К слову сказать, в Oracle 11 реализована похожая вещь на системном уровне. плюс Ораклу за это. Но этот вопрос не так интересен, потому что понятен смысл такого логирования. Он имеет право на жизнь и достаточно востребован, чтобы его реализовывать, как с использованием системных средств, так и самодельно tru551. здесь рассматривается достаточно узкий случай. Как правило, к базе можно доступиться не только через разработанную клиентскую программу, но и другими инструментами 2. для чего - я уже сказал выше - доп. уровень защитынормальная система разграничения доступа решает эти проблемы значительно проще и на мой вкус, правильней воспользоваться ей, чем городить свой велосипед. 3. по поводу производительности: >> - поскольку это логирование включается периодически, то влияние не столь велико - вот с какого, интересно? если логирование производится в момент, когда возникли подозрения, то проще смотреть permissions пользователя/группы пользователей, чем запускать логирование, неизвестно, как долго придётся ждать, когда в следующий раз будет вызвана хранимая процедура именно тем пользователем, которому вызывать её не положено, и остальные будут испытывать неудобства всё это время совершенно незаслуженно. Потом, если уж человек добрался до базы через другой инструмент, то уж наверное он сообразит сделать SELECT напрямую, не используя хранимую процедуру, то есть этот инструмент защиты будет обойдён. Так в чём же смысл, я вас спрашиваю? >> - есть куча не сильно нагруженных систем, на которых эта доп. добавка просто будет незаметна - имхо, в несильно нагруженных системах тем более нет необходимости логировать селекты в хранимках, там и так можно разобраться. >> - за любой сервис надо платить. Скажем, в Oracle с 10 версии по умолчанию работает >> постоянный сбор статистики работы, что можно использовать для мониторинга >> производительности базы, отлова "тяжелого" SQL и проч. Естественно, это доп. нагрузка на >> сервер. Поэтому, если производительность критична, то эту систему отключают, теряя при этом >> помянутые удобства - не видите здесь противоречия? чтобы отловить тяжёлый SQL мы добавляем в систему средство, которое заведомо утяжелит всю систему? tru554. "сделано" - это не общие рассуждения. Если люди реализовывали это на уровне СУБД (Oracle), значит подобная вещь имеет спросзнаете зачем? чтобы поменьше было велосипедов. Моё имхо в том, что подобное средство встроено в СУБД скорее для наладки производительности в помощь DBA, а не для реализации мифических дополнительных уровней защиты. Ну и маркетинговый ход, само собой: "вона чего мы умеем, ни у кого такого нет!" В этом смысле Oracle не сильно отличается от Microsoft. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 18:36 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55egorych чего можно разобрать, если мы знаем, что пользователь Х 197 раз в день обновил у себя в клиентской программе грид с данными? зачем нужны эти сведения? что полезного мы можем из них почерпнуть? и стоит ли ради их получения увеличивать время разработки и просаживать производительность? - вот вопросы, ответы на которые хочется получить, а не общие рассуждения, что "мол, надо" и "мол, сделано". 1. здесь рассматривается достаточно узкий случай. Как правило, к базе можно доступиться не только через разработанную клиентскую программу, но и другими инструментамиэтот узкий случай и есть самая частая операция выборки данных из базы. Она выполняется по тыще раз на дню каждым пользователем и представления для таких гридов, как правило и являются одними из ( или даже самыми ) тяжёлыми выборками, а вы предлагаете к ним прикрутить ещё и лог. Кстати, ответов на вопросы я так и не получил )) ЗЫ сорри за многабукаф )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2009, 18:40 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
iscrafmspей надо знать, а смотрел ли и когда, жели бы вы работали в более или менее серьезной конторе - там бы вы с этим столкнулись - т.к. наличие ауидита - это аттрибут любой мало-мальски серьезной системы в "серьезных конторах" не работал, но что-то мне подсказывает, что полезно знать кто, что и когда сделал. когда начинаются разборки кто слил конкурентам информацию - надо же знать кто смотрел, одну ли запись или просто делал выборку всех данных по-очереди если у вас такого не было, то это не означает что такого небывает ваабче - у нас в банке так и вычислили кто сливает информацию налево за деньги ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 08:13 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
egorychи зачем это надо знать? хоть кто-нить может вразумительно ответить, а не на уровне общих рассуждений читайте выше - я описал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 08:17 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
egorychtru55Информация бывает открытая и закрытая (по крайней мере, для части публики). Способы скрыть инфу от "ненужных" глаз бывают разные, в том числе и аудит (в смысле логирования)...вы издеваетесь? как логирование может чего-то скрыть? логирование фиксирует факт совершения операции. да и странно почему все привязались к логгированию - это одна из функций селект-хп основное ее назначение для каждой роли в системе выдавать свои данные и там не просто показать или непоказать колоначку - там бывает довольно таки сложная логика - т.к. роли разные и кормят их по-разному )))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 08:19 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
spiscrafmspей надо знать, а смотрел ли и когда, жели бы вы работали в более или менее серьезной конторе - там бы вы с этим столкнулись - т.к. наличие ауидита - это аттрибут любой мало-мальски серьезной системы в "серьезных конторах" не работал, но что-то мне подсказывает, что полезно знать кто, что и когда сделал. когда начинаются разборки кто слил конкурентам информацию - надо же знать кто смотрел, одну ли запись или просто делал выборку всех данных по-очереди если у вас такого не было, то это не означает что такого небывает ваабче - у нас в банке так и вычислили кто сливает информацию налево за деньги у меня такого не бывает, потому что на чтение той или иной информации выдаются конкретные полномочия, конкретным людям . Если "слита" информация, то круг людей, имеющих к ней доступ заранее известен. Каким боком здесь логи селектов даже Пуаро не въедет. Или считаете что если информация слита в 12:10, то слил ее тот кто прочитал наиболее близко к этому времени? Я пошутил насчет "серьезных" контор, Вы подтвердили "серьезность". p.s. "серьезные пацаны" слово ваабче пишут как вообще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 10:37 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
egorych нормальная система разграничения доступа решает эти проблемы значительно проще и на мой вкус, правильней воспользоваться ей, чем городить свой велосипед. 1. я не говорил, что не надо пользоваться разграничением доступа. Система логирования - это в дополнение, а не вместо 2. по поводу обхода защиты (а пользование другим инструментом - один из них) я уже тоже говорил egorych - вот с какого, интересно? если логирование производится в момент, когда возникли подозрения, то проще смотреть permissions пользователя/группы пользователей, чем запускать логирование, неизвестно, как долго придётся ждать, когда в следующий раз будет вызвана хранимая процедура именно тем пользователем, которому вызывать её не положено, и остальные будут испытывать неудобства всё это время совершенно незаслуженно. Потом, если уж человек добрался до базы через другой инструмент, то уж наверное он сообразит сделать SELECT напрямую, не используя хранимую процедуру, то есть этот инструмент защиты будет обойдён. Так в чём же смысл, я вас спрашиваю? 1. одними permissions сыт не будешь, тем паче, что на них уже смотрели раньше 2. возможность SELECT-а напрямую опять же зависит от прав 3. использование хранимых процедур в том числе для целей логирования декларировал не я, а другой оратор. Я говорил про системные средства Oracle. Они либо не требуют программирования (стандартный аудит), либо требуют некоторого программирования (FGA), но это накладывается на таблицу, а не пихается в каждую процедуру egorych - имхо, в несильно нагруженных системах тем более нет необходимости логировать селекты в хранимках, там и так можно разобраться. 1. Хм-м-м... Т.е. если система сильно нагружена (скажем, несколько сот одновременно работающих), то нам разбираться некогда, а если несколько десятков - то есть куча времени на разборы? Ор-р-ригинально... 2. про логирование именно в хранимках смотри выше... egorych - не видите здесь противоречия? чтобы отловить тяжёлый SQL мы добавляем в систему средство, которое заведомо утяжелит всю систему? Абсолютно не вижу. А как его отлавливать, не запускаю доп. функциональность? А доп. функциональность в любом случае создает нагрузку (то же декларируемое логирование DML). За все надо платить (см. пред. посты) egorych знаете зачем? чтобы поменьше было велосипедов. Моё имхо в том, что подобное средство встроено в СУБД скорее для наладки производительности в помощь DBA, а не для реализации мифических дополнительных уровней защиты. Ну и маркетинговый ход, само собой: "вона чего мы умеем, ни у кого такого нет!" В этом смысле Oracle не сильно отличается от Microsoft. 1. на самом деле возможных уровней защиты в Oracle значительно больше, включая "шифрование на лету". Видимо, все они мифические, если вполне достаточно системы грантов. 2. логирование SELECT не может (или редко может) помочь в настройке производительности, ибо там отсутствуют планы выполнения, временные характеристики запроса 3. Ну разумеется. Все, что МНЕ кажется ненужным, это маркетинговые ходы и не более того. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 10:51 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
spда и странно почему все привязались к логгированию - это одна из функций селект-хп основное ее назначение для каждой роли в системе выдавать свои данные и там не просто показать или непоказать колоначку - там бывает довольно таки сложная логика - т.к. роли разные и кормят их по-разному ))))ну не все, в основном мне стало интересно, зачем? как к таковым select-процедурам у меня никакого предубеждения нету, смысл их использования понятен. Резюмируя, скажу, что смысла в логах селектов до сих пор не вижу. Единственное, что я понял, зачем вы их используете, но считаю, что тех же целей можно было бы достичь и другими, более правильными и менее затратными способами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 10:54 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
egorych этот узкий случай и есть самая частая операция выборки данных из базы. Она выполняется по тыще раз на дню каждым пользователем и представления для таких гридов, как правило и являются одними из ( или даже самыми ) тяжёлыми выборками, а вы предлагаете к ним прикрутить ещё и лог. 1. как раз выборки в гриды (если мы под этим понимаем одно и то же) чаще всего НЕ являются тяжелыми выборками, ибо для визуального наблюдения больших объемов не нужно. Самыми тяжелыми выборками, как правило, являются некоторые отчеты 2. если выборка тяжелая, она занимает кучу времени и пользователь просто не станет по долгу ждать ее вывода на экран (отчеты - это другое дело). Кроме того, тяжелые выборки выполняются от десятков минут до нескольких часов и пользователь тысячу раз в день просто не сможет ее запустить 3. может мы по разному понимаем лог? Если выборка тяжелая, то время ее выполнения значительно превышает время разбора SQL и в этом случае запись текста SQL в какую-то табличку (один из вариантов логирования) добавит даже не копейки, а доли копеек к общему времени ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 11:00 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55Если выборка тяжелая, то время ее выполнения значительно превышает время разбора SQL и в этом случае запись текста SQL в какую-то табличку (один из вариантов логирования) добавит даже не копейки, а доли копеек к общему времени Вы не знаете этот текст и пишете для того, чтобы посмотреть что в нем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 11:03 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55, я вам улыбаюсь )) я говорю об отсутствии необходимости логирования селектов в хранимых процедурах, а вы про системные возможности Оракла, хоть в этом вы противоречие видите? Мне не интересно, честно говоря, зачем в Оракл прикрутили такую функциональность, это дело компании Оракл. Мне даже не интересно, зачем вы проводите в топике рекламную компанию определённого вендора, хотя разговор ведётся "в общем виде". Единственное, что мне было интересно в рамках треда, зачем топик-стартер использует лог селектов в хранимых процедурах в своей системе. Я это выяснил. Остался не согласным, но по крайней мере понял идею. Ха, можете считать это сливом ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 11:05 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
iscrafmtru55Если выборка тяжелая, то время ее выполнения значительно превышает время разбора SQL и в этом случае запись текста SQL в какую-то табличку (один из вариантов логирования) добавит даже не копейки, а доли копеек к общему времени Вы не знаете этот текст и пишете для того, чтобы посмотреть что в нем? 1. если доступ не через приложение, то не знаю 2. есть такое понятие, как dynamic SQL, когда текст формируется налету в зависимости от конкретных условий 3. время и место посылки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 11:06 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55, простите, я вам улыбнусь ещё раз ))) вообще разговор в треде начался с 4х CRUD-процедур на каждую таблицу, в количестве которых ТС стал путаться, потом поговорили о необходимости селективной процедуры в этой связке, а потом выяснилось, что в ЭТИХ процедурах введён лог селектов. Причём тут отчёты и запросы, выполняющиеся от десятков минут до нескольких часов? Они вообще не рассматриваются в этой теме. Вы уж простите, может вам топик перечитать с самого начала, чтобы понять о чём речь в треде ведётся? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 11:13 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru551. если доступ не через приложение, то не знаю 2. есть такое понятие, как dynamic SQL, когда текст формируется налету в зависимости от конкретных условий 3. время и место посылки 1. чуть выше шла речь о серьезных конторах... 2. DSQL от балды не формируется. Или имеется софт, где пользователь может написать любой текст запроса и отправить его на исполнение? 3. увидел что пользователь А делал select tr from whlog 10 раз, последний - 15 минут назад. И что? У него есть право этим заниматься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 11:13 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
egorychtru55, я вам улыбаюсь )) Да на здоровье egorych я говорю об отсутствии необходимости логирования селектов в хранимых процедурах, а вы про системные возможности Оракла, хоть в этом вы противоречие видите? Первый вопрос прозвучал здесь /topic/713143&pg=1#7969162 Фраза была о необходимости логировать SELECT вообще, а не конкретно в хранимых процедурах. То, что в Oracle есть функциональность, позволяющая избежать кодирования этого в каждой процедуре, всего лишь упрощает разработку, но принцип необходимости логирования от этого не меняется egorych Мне не интересно, честно говоря, зачем в Оракл прикрутили такую функциональность, это дело компании Оракл. Мне даже не интересно, зачем вы проводите в топике рекламную компанию определённого вендора, хотя разговор ведётся "в общем виде". Рекламой я не занимаюсь, не зачем мне это. Я привожу пример Oracle всего лишь потому, что знаю эту СУБД лучше других. Или мы отрицаем опыт других и доверяем только своему "чутью"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 11:14 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
egorych Причём тут отчёты и запросы, выполняющиеся от десятков минут до нескольких часов? Они вообще не рассматриваются в этой теме. Вы уж простите, может вам топик перечитать с самого начала, чтобы понять о чём речь в треде ведётся? Да ну? А кто упомянул про тяжелые запросы, да еще выдаваемые по "тыще в день"? По поводу "прочитать с начала" - не имею привычки читать несколько последних сообщений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 11:17 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
iscrafmtru551. если доступ не через приложение, то не знаю 2. есть такое понятие, как dynamic SQL, когда текст формируется налету в зависимости от конкретных условий 3. время и место посылки 1. чуть выше шла речь о серьезных конторах... 2. DSQL от балды не формируется. Или имеется софт, где пользователь может написать любой текст запроса и отправить его на исполнение? 3. увидел что пользователь А делал select tr from whlog 10 раз, последний - 15 минут назад. И что? У него есть право этим заниматься. 1. и что? Тем паче, что "серьезная контора" - понятие растяжимое 2. DSQL формируется не от балды, но в некоторых случаях без него просто не обойтись. Поэтому как правило, в серьезных (:) ) системах он присутствует, вопрос только в количестве 3. про достаточность этих самых прав я уже говорил неоднократно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 11:20 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru551. и что? Тем паче, что "серьезная контора" - понятие растяжимое 2. DSQL формируется не от балды, но в некоторых случаях без него просто не обойтись. Поэтому как правило, в серьезных (:) ) системах он присутствует, вопрос только в количестве 3. про достаточность этих самых прав я уже говорил неоднократно 2. Если он не от балды формируется, то каким образом получается что его текст не известен. (у нас наверное разные понимание DSQL. Я под этим термином понимаю запрос, который получает СУБД извне) 3. Не знаю кому и что говорили, но они достаточны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 11:25 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55По поводу "прочитать с начала" - не имею привычки читать несколько последних сообщений.Да ну? А чего же вы даёте ссылки из середины треда, и без учёта контекста, который был задан цитатой в этом сообщении? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 11:29 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
Аудит селектов - полезен, просто не всегда. Более всего он полезен, когда о нем не знают. Есть некая информация, в виде отчета. Информация для ограниченного доступа, круг лиц ограничен, к примеру, 5 людьми. Инфа уходит на сторону, причем понятно, что так как инфа за такой-то период, то ее не могли сдать люди, которые формировали отчет ранее этого периода, и люди, которые формировали отчет после этого периода, но не за этот период. Смотрим аудит. Конечно, если окажется, что все 5 человек сделали это, то аудит не поможет. Но если хотя бы 4 - то это позволит отмести 1-го подозреваемого. А если окажется, что данные смотрел только один - выйти на нужного человека. Соответственно, такой аудит нужен, когда информация действительно стоит денег... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 11:41 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
iscrafmtru551. и что? Тем паче, что "серьезная контора" - понятие растяжимое 2. DSQL формируется не от балды, но в некоторых случаях без него просто не обойтись. Поэтому как правило, в серьезных (:) ) системах он присутствует, вопрос только в количестве 3. про достаточность этих самых прав я уже говорил неоднократно 2. Если он не от балды формируется, то каким образом получается что его текст не известен. (у нас наверное разные понимание DSQL. Я под этим термином понимаю запрос, который получает СУБД извне) 3. Не знаю кому и что говорили, но они достаточны. 2a) разумеется неизвестен, и что? 2б) причем здесь извне? Можно и статический SQL получать извне (с клиента) и динамический формировать в ХП 3) в таких случаях принято добавлять ИМХО, поскольку мысль спорна ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 11:41 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
egorychtru55По поводу "прочитать с начала" - не имею привычки читать несколько последних сообщений.Да ну? А чего же вы даёте ссылки из середины треда, и без учёта контекста, который был задан цитатой в этом сообщении? 1. тогда надо точнее формулировать 2. я уже сказал выше, что логирование из своей процедуры или системными средствами - вопрос удобства, на принцип необходимости (хотя бы иногда) не влияет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 11:43 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru551. тогда надо точнее формулироватьдецкий сад, штаны на лямках... вы хоть осознаёте, что вопрос я задавал не вам? ну да ладно, давайте по другому зайдём: tru55 iscrafmtru55 ... 3. про достаточность этих самых прав я уже говорил неоднократно 3. Не знаю кому и что говорили, но они достаточны. ... 3) в таких случаях принято добавлять ИМХО, поскольку мысль спорна правила написания ИМХО относится только к iscrafm? высказывая свою мысль о недостаточности системы разграничения прав доступа, вы тоже имхо не употребляли, кажется. Давайте тогда конкретно говорить, в чём, по вашему мнению, заключается недостаточность системы безопасности СУБД, скажем Oracle, в контексте разговора. Причём настолько, что требуется вводить дополнительную систему логирования селективных запросов. Желательно, конечно, чтобы разговор касался CRUD-процедур. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 12:01 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55 2a) разумеется неизвестен, и что? 2б) причем здесь извне? Можно и статический SQL получать извне (с клиента) и динамический формировать в ХП 3) в таких случаях принято добавлять ИМХО, поскольку мысль спорна 2а- Если в системе неизвестно какие запросы могут быть отправлены СУБД, то конечно. Логи нужны. Я просто не рассматривал случаи когда у прикладных пользователей TOAD (QA) используется для формирования запросов. 2б - динамическим он называется не от того, что формируется каким-то образом, а потому, что не сохранен в БД в доступной для этого форме. 3) имхо. Хотя с учетом 2а-б возникает понимание в чем их недостаточность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 12:28 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
TOAD здесь ни причем. Есть разные случаи, когда без динамического SQL (вызываемого на выполнение через EXECUTE IMMEDIATE) не обойтись. Приведу один пример. В OeBS есть так называемые гибкие поля. Эта вещь предназначена для настройки системы без участия программиста. Реализовано это так: в таблицах, где эта настройка позволяется, заведена куча доп. полей с именами ATTRIBUTE1..ATTRIBUTE30 (или SEGMENT1...). При настройке аттрибута в системных таблицах прописывается его контекст (что означает, приглашение в форме и проч.). Если серверов несколько, то существует 2 подхода к таким настройкам (работал с обоими): либо эта настройка прописывается в какой-то доке и на всех серверах настраивается на 1 поле (например, attribute5), либо указывается только необходимость настройки, а на какое поле - пользователь (привилегированный пользователь) решает при выполнении этой настройки. Выбор способа зависит от заказчика, поэтому не обсуждается. Так вот, во втором случае когда я пишу SELECT, я заранее не знаю, на какое поле настройка (программа, разумеется, должна работать на всех серверах). Поэтому я сначала SELECT-ом по системным таблицам вытаскиваю имя поля, а потом формирую динамический SELECT, подставляя в него полученное имя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 13:11 |
|
||
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#18+
tru55, понятно откуда "ноги растут", спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2009, 13:23 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1542962]: |
0ms |
get settings: |
5ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
180ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
115ms |
get tp. blocked users: |
1ms |
| others: | 205ms |
| total: | 543ms |

| 0 / 0 |
