ДБА! Пишите ли вы директивы для программеров?

The_Which
Дата: 21.02.2007 17:50:31
начальник озадачил меня (как ДБА) написть директивы (т.е. перечень основных правил постоянного соблюдения) для наших программеров (SQL, PL/SQL). По смыслу писать действительно больше чем достаточно. (ибо уровень здешнего кода ещё улучшать и улучшать!)

Но хотелось бы узнать: нет ли у кого стандартов по написанию внутренних директив? Bозможно даже ISO-шных? (в предыдущей своей конторе писал таковые "в свободной форме", ceйчас хотелось бы написать как-то кошерно...)

Спасибо!
Elic
Дата: 21.02.2007 18:00:00
Была такая шняга на форуме.
Sevick
Дата: 21.02.2007 20:10:58
The_Which
начальник озадачил меня (как ДБА) написть директивы (т.е. перечень основных правил постоянного соблюдения) для наших программеров (SQL, PL/SQL). По смыслу писать действительно больше чем достаточно. (ибо уровень здешнего кода ещё улучшать и улучшать!)

Но хотелось бы узнать: нет ли у кого стандартов по написанию внутренних директив? Bозможно даже ISO-шных? (в предыдущей своей конторе писал таковые "в свободной форме", ceйчас хотелось бы написать как-то кошерно...)

Спасибо!


Если по-хорошему - отправить на оракловые курсы.
Если "как всегда" - рассказать про избранные аспекты поведения оракла, которые их касаются и заставить разбирать пятничные задачи Elic вплоть до полного понимания -)
Sevick
Дата: 21.02.2007 20:11:57
The_Which
начальник озадачил меня (как ДБА) написть директивы (т.е. перечень основных правил постоянного соблюдения) для наших программеров (SQL, PL/SQL). По смыслу писать действительно больше чем достаточно. (ибо уровень здешнего кода ещё улучшать и улучшать!)

Но хотелось бы узнать: нет ли у кого стандартов по написанию внутренних директив? Bозможно даже ISO-шных? (в предыдущей своей конторе писал таковые "в свободной форме", ceйчас хотелось бы написать как-то кошерно...)

Спасибо!


Кошерно - это точно на курсы.
Всех на программерские, а одного (самого способного) - еще и на админские
dkflbvbh
Дата: 22.02.2007 09:02:27
Может для начала рассказать им что такое стоимость запроса и как пользоваться планом запроса.
RA\/EN
Дата: 22.02.2007 11:20:57
dkflbvbh
Может для начала рассказать им что такое стоимость запроса и как пользоваться планом запроса.

А необходимость есть? Как бы не освистали за попытку впарить лекцию про COST.
softwarer
Дата: 22.02.2007 11:43:14
Elic
Была такая шняга на форуме.

И такая
RA\/EN
Дата: 22.02.2007 14:30:44
softwarer
Elic
Была такая шняга на форуме.

И такая

С точки зрения не очень начинающего...

1. Будь проще - используй альясы.
+1
2. Селекты старайся писать во фром.
Обоснуйте...
3. Минимизируй использование функций во въюхах.
Из принципа? "Не используй функции там, где сойдет скалярный поздапрос".
4. Побольше процедур нужных и разных.
Нафиг-нафик. Не плодить процедур, если можно доработать существующие!
5. Въюха + въюха+.....+въюха = смерть.
Правда что-ли?
6. За временные таблицы тебя не убъют.
А за использование временных таблиц вместо небольшого усложнения запроса - вполне могут.
7. Следи за "мусором".
За "мусором" пусть JRE следит
8. "Что это? номер кредитной карточки?"....нет это кост:)). За наименьший кост.
Не делайте из коста идола. Оптимизатор в жизни не угадает кост при джойне уже трех таблиц с неравномерными данными в полях, участвующих в условиях и джойнах.
9. replace
и coalesce!
10. Явно назвай все констрейнты (возможное послабление - not null).
+1
11. Явно называй все индексы.
+1
12. За названия объектов prihod, rashod, lagerbereiche, st_pr_q_val_sum_updt тебя убьют.
+1
13. За DDL как часть боевого кода тебя убьют.
It depends...
14. Не вылезай за пределы своей схемы.
Почему бы и нет?
15. Не создавай индексов без нужды.
+1
16. Создавай индексы, если это необходимо.
Перед этим 15 раз подумать над п.15
17. Комментируй таблицы, триггеры и процедуры.
+1
18. Во всём нужно знать меру.
...
19. Если в чем не уверен, спроси у DBA
Лучше подумать своей головой
20. Если DBA в наличии не имеется, goto www.sql.ru
+1
21. Написал SQL, посмотри план. Если в запросе больше одной таблицы - посмотри обязательно.
Если в запросе больше трех таблиц - запрос изначально написал не самым быстрым способом.
Смотри план и меняй запрос.
Рекурсия...
22. Значения нужно передавать в запросы через bind-переменные !!!
Не всегда. Пикинг может нагадить так, что неделю разбираться будешь.
23. Не изобретай велосипед, вдруг это кто-нибудь писал.
Обычно находятся какие-то трехколесные и без педалей...
24. Умей слушать постановщика.
Фильтруй бред
25. Умей спорить.
+1 Но не зацикливайся на собственном мнении.
26. Не занимайся ерундой. Не нужно ставить автомат на сливной бачек.
+1
27. Умей говорить и писать так, чтобы тебя понял и коллега, и пользователь.
+1
28. Прочти документацию прежде чем сделать какую-нибудь глупость
+100. Глупость, в т.ч. - тупой вопрос на sql.ru
29. Всегда слушай DBA - он мудрый человек
Недаром в RPG Wisdom и Intelligence - разные скиллы
30. Умей рисковать и не слушай DBA. Все DBA трусы
+1
Elic
Дата: 22.02.2007 14:37:41
RA\/EN
softwarer
И такая
С точки зрения не очень начинающего...
Но в целом всё-таки неплохие советы, особенно для начинающих :)
The_Which
Дата: 22.02.2007 15:14:29
Нафиг-нафик. Не плодить процедур, если можно доработать существующие!

it depends! Но вообще, общий принцип современной software-разработки гласит: "код должен быть закрыт для изменений и открыт для расширений!"