|
|
|
правильна ли стратегия разработки? или я не туда забрел?
|
|||
|---|---|---|---|
|
#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 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36320184&tid=1542962]: |
0ms |
get settings: |
7ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
158ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
87ms |
get tp. blocked users: |
1ms |
| others: | 205ms |
| total: | 496ms |

| 0 / 0 |
