Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 21   вперед  Ctrl
 Re: Админы! за что вы убивали бы разработчиков?  [new]
muller
Member

Откуда: Москва
Сообщений: 925
Я думаю так:
Разработчик, пишущий плохие программы ( глючные, медленные и т.п. ) -- это плохой разработчик.
Плохому разработчику должно быть плохо. ( он должен получать больше звиздюлей и меньше денег ). Дискридитировавший себя разработчик должен быть уволен.
Определение качества работы девелопера ( на "тестовом сервере" ) -- это функция "группы приёмки". Если ( скажем ) тестировщик со своими правами не может реботать с программой, то он берёт из угла поганую метлу и идёт с ней к лидеру разработчиков.
Если среди "группы приёмки" есть "админ" и этот "админ" видит "криминал", он снова берёт поганую метлу и повторяет алгоритм "тестировщика".
( что такое "криминал" должно быть оговорено и, желательно, зафиксировано письменно. Главный Разработчик, получая в морду поганой метлой, должен испытывать стыд, а не возмущение несправеливостью наездов )
Лидер разработчиков, получив люлей, распространяет их среди подчинённых.
Таким образом качество продукта повышается, шлифуются подходы, предлагаются новые решения и т.п.

А если, ребята, у вас не поставлен процесс разработки, то вместо помощи и поддержки получаются дрязги и заявы вроде
Scott Tiger
Девелоперу должно быть сложно и неуютно...


PS Спасибо всем "админам", научившим меня "жизни". А тем, кто ###нёй мается -- нет моего спасиба.
8))
3 май 05, 12:35    [1512894]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64009
Блог
AI
Я бы увольнял любого админа, не дающего разработчикам доступ на файлы трассировки (10046/10053...). Заодно и на некоторые представления словаря вроде v$sesstat.

Хм. Единственно, хоть я и разработчик, я бы упомянул о том, что на некоторых production-ах админу разумнее контролировать это руками. Трассировка - достаточно нагрузная задача, по моим наблюдениям.

[off]Вспоминая, как оставленный с открытым ftp-окном FAR однажды ночью накачал пару гигов траффика - постоянно перечитывая список файлов в очень большом каталоге. Случаи - они разные бывают.[/off]
3 май 05, 12:37    [1512905]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
RA\/EN
Member

Откуда:
Сообщений: 3659
2Apex:

За такое надо убивать админа. Предположим, у вас заказчик работает на 4-процессорном Opteron'е, максимум 10 активных пользователей. Вы тратите время на оптимизацию на дохлом селере, доводите код до "совершенства", оптимизируя запросы, которые выполняются раз в неделю, расходуете сотни человеко-часов, и все ради того, что на production-сервере среднее ускорение составлило 10% от неоптимизированного кода (а пользователи этого могут вообще не заметить). За такое обычно заказчик не платит, а в результате проектная прибыль уменьшается на те самые (100..200..500)*(X$/чч) = (большая сумма).

А все из-за админа-иделаиста. Идея - штафануть его на эту сумму :)

Знаю крупную телекоммуникационную компанию, у которой сервисы висят на дохлейших машинах, работают неоптимально, но, самое важное - их УСТРАИВАЕТ, и они не будут покупать новое железо или новую версию софта, чтобы у них заработало даже в 2 раза быстрее.

Первое правило оптимизации: софт должен работать не просто быстро, и не максимально быстро, а ПРИЕМЛЕМО БЫСТРО.
3 май 05, 12:37    [1512906]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64009
Блог
Bdfyxer\b\b\b\b\b\b\b Иванчук
Разработки с тестовой базы идут прямиком на продакшн, ....
Тестовая база должна воспроизводит продакшн - чем точнее, тем лучше.

Различайте "тестовую базу" и "базу для разработки".
3 май 05, 12:41    [1512918]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6876
RA\/EN
2Apex:

За такое надо убивать админа. Предположим, у вас заказчик работает на 4-процессорном Opteron'е, максимум 10 активных пользователей. Вы тратите время на оптимизацию на дохлом селере, доводите код до "совершенства", оптимизируя запросы, которые выполняются раз в неделю, расходуете сотни человеко-часов, и все ради того, что на production-сервере среднее ускорение составлило 10% от неоптимизированного кода (а пользователи этого могут вообще не заметить). За такое обычно заказчик не платит, а в результате проектная прибыль уменьшается на те самые (100..200..500)*(X$/чч) = (большая сумма).

А все из-за админа-иделаиста. Идея - штафануть его на эту сумму :)

Знаю крупную телекоммуникационную компанию, у которой сервисы висят на дохлейших машинах, работают неоптимально, но, самое важное - их УСТРАИВАЕТ, и они не будут покупать новое железо или новую версию софта, чтобы у них заработало даже в 2 раза быстрее.

Первое правило оптимизации: софт должен работать не просто быстро, и не максимально быстро, а ПРИЕМЛЕМО БЫСТРО.


Опять-таки - во всём нужно знать меру. В том числе и заказчику, который под 10 юзеров (без роста в будущем) берёт 4-процессорный оптерон. Примлимо быстро - хорошее понятие, проблема только в том, что с течением времени изменяется ряд факторов, таких как количество пользователей и объём данных, что выпячивает наружу недостатки разработки, и на том же железе всё начинает работать нестерпимо медленно.
Большая проблема подавляющего большинства разработчиков заключается в их очень низкой квалификации. Типичный разработчик не знает, что такое логическое чтение, не умеет получать и анализировать план выполнения запроса, часто даже не знает, что такое план, знает о существовании только "фуллскана" и "по индексу", естественно, не знает о содержимом v$-представлений, способах включения трассировки и анализа трассировочных файлов и т.п. - можно продолжать очень и очень долго. О какой производительности решений, написанных подобными деятелями, можно рассуждать? Плохо оно или хорошо работает - воля случая...
3 май 05, 13:02    [1513005]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
use-se
Member

Откуда: Москва
Сообщений: 449
Apex
Scott Tiger
Девелоперу должно быть сложно и неуютно, а девелоперская БД должна жить на максимально тормозной машине, что способствует написанию быстро работающего кода.

А вот с этим согласен на все 100! Имеется личный опыт, когда переносили код с InterBase на Oracle, то одна из процедур под Oracle работала в 10 раз медленее, при этом мы ошибочно думали, что наша тестовая база лежит на 2-процовом серваке, при том, что тестовый InterBase крутился на каком-то селероне... Осознавая, что нас за такое переписывание просто не поймут, занялись оптимизацией. В результате добились приемлемого времени исполнения (почти одинакового), а уже потом нам админ сказал, что все было наоборот: наша оракловая база лежала на селероне с 512 RAM, а InterBase на 2-х проциковом Xeon с 2Гб RAM

Не согласен на все 100%.
1. Это (ИМХО: ложное), не обоснованное предположение. Если следовать этой логике, то все что разрабатывается на слабых тестовых серверах будет работать на УРА и, наоборот. Качество программного кода (ИМХО) исключительно зависит от квалификации разработчика и его ресурсах (временной ресурс, финансовый ресурс - зарплата и т.п.). Сознательно ставя разработчика в тяжелые условия труда, Вы тем самым сознательно урезаете его временной ресурс.
2. Психологический аспект противостояния: администратор - разработчик. Думаю не стоит говорить что думает человек, когда ему создают дополнительные трудности?
3. Как правило если разработчик имеет какие либо ограничения к минимальной конфигурации, то он автоматически урезает уровень сервиса для заказчика. В результате заказчик получает "немного не то, что заказал".
4. Далее по этой фразе должно следовать, по аналогии: "ДБА должно быть сложно и неуютно......". Что если Ваша "тестовая" машина на которой Вы отрабатываете Экспорт/Импорт и т.п. будет "жить на максимально тормозной машине", только не тормозной а глючной машине? Будет ли это способствовать вашей работе?

Что касается дополнительных привелегий, фраза: "Аналогично и поднятые привилегии на девелоперской базе способствуют написанию кода, который невозможно поставить в production". Освещается в этом топике только с одной стороны. Большинство разработчиков работают по схеме с 2-мя, 3-мя аккаунтами:
Первый: разработчик - непосредственная реализация бизнес-логики приложения. Здесь не используются какие либо дополнительные привелегии, за исключением тех, которые нужны для различного рода инструментария;
Второй: пользователь - используется исключительно для тестирования;
Третий: ДБА. Этот аккаунт нужен для иследования отдельных моментов. ПОД НИМ РАЗРАБОТЧИК НЕ РАБОТАЕТ И НЕ СТРОИТ БИЗНЕС-ЛОГИКУ.
3 май 05, 13:03    [1513012]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
Borland
Member

Откуда: $HOME
Сообщений: 15839
2 use-se : Вот не надо путать белое с пушистым: есть три категории серверов: девелоперские, тестовые, продуктивные. На девелоперском сервере разработчики могут творить всё что угодно, но если девелоперский и тестовый совпадают, то там никаких административных привелегий и доступа к словарю данных у разработчика не будет. Тем более их не будет на продуктивном сервере. А когда я отбираю права SYSDBA у пользователя-владельца основной схемы, зачастую прибегают администраторы приложений(читайте пользователи) и говорят, что у нас перестал работать такой-то модуль. При таком способе разработки я бы и на девелоперских ничего не давал разработчику. А если разработчику просто интересно, что там в словаре лежит, и ему это не нужно для работы, то он идёт лесом домой ставить себе дома оракл и дома удовлетворять свой интерес с dictionary.

-----
Все великие дела совершаются в командной строке
3 май 05, 13:47    [1513220]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
Simon
Member

Откуда:
Сообщений: 974
ну блин народ вы тут и понаписали:)

читаю и ржу:)

пусть мне кто-нибудь объяснит чем:
1. написание
select ole1, pole2 from table
лучше чем
select * from table
если в таблице всего два поля
2. про триггеры на update без перечисления колонок
(для кого на металинке поискать баги, связанные с перечислением колонок?)

особенно меня радует, что dba подходят к вопросу с точки зрения облегчения их существования, а не с точки зрения того что будет лучше для разрабатываемой системы
3 май 05, 13:47    [1513224]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
Bdfyxer\b\b\b\b\b\b\b Иванчук
Guest
use-se
Bdfyxer\b\b\b\b\b\b\b Иванчук
use-se
[quot Borland][quot serg1257]

ДБА, который на БД предназначенной для разработки требует "чёткое обоснование требовния доступа к словарю", всегда будет иметь много лишней работы.

Поэтому я выше и написал, что на тестовой БД разработчик должен иметь привелегию ДБА, что бы не обосноввывать....


Разработки с тестовой базы идут прямиком на продакшн, и очень часто это бывает в режиме "желательно вчера". В этих условиях кто будет разгребать то, что разработчик не отследил использование таблиц словаря и сколько на этом будет потеряно времени?
Тестовая база должна воспроизводит продакшн - чем точнее, тем лучше. В том числе и по привилегиям.

Вот, вот поблема в том, что: в режиме "желательно вчера". И вместо правильной организации работ мы идем "прямым путем", типа запретить все.
Добро пожаловать в реальный мир! Сроки мы не назначаем себе сами, их нам ставит руководство. Если есть что обсудить по поводу сроков и организации, это не к админам и не к девелоперам, это к руководству.

В советское время много чего запрещали и можно подумать все так и поступали как было написано в инструкциях.

Вы бы еще Гитлера приплели Не надо демагогии, мы все таки технические специалисты, а не политики.

Что касается представлений словаря, то здесь при разумном подходе, можно получить существенную выгоду. Например, проверив наличие у пользователя какой либо роли можно реализовать на клиенте, дополнительную логику (сделать не активными/не видимыми отдельные компоненты приложения). Вопрос только в балансе, разумном подходе при проектировании приложения, а ограничений у разработчика и так достаточно.

Кстати, если ДБА старается все "закрыть", то большинство разработчиков не будет, что либо доказывать, а просто переносят логику на клиент и все. А на клиенте раздолье: зачем, к примеру, делать связанные переменные - сделаем динамически генерируемые на клиенте запросы вида 'WHERE FIELD1=' +'Вася'. А теперь как ДБА оцените, что для Вас важнее: один раз отловить ошибки при переносе на продакшен или каждый день смотреть, что приходит с клиентских приложений.
Ключевые слова: при разумном подходе. Против разумного подхода ничего не имею. Кстати, свои роли пользовательская сессия всегда может посмотреть.

2 softwarer: я имею "маленькое" представление о разнице между серверами для разработчиков и для тестеров, но считаю, что в данном случае разница между ними малосущественна.
3 май 05, 14:19    [1513364]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
muller
Member

Откуда: Москва
Сообщений: 925
Borland
А если разработчику просто интересно, что там в словаре лежит, и ему это не нужно для работы, то он идёт лесом домой ставить себе дома оракл и дома удовлетворять свой интерес с dictionary.

Вот мне интересно, товарищ, кто Ваш лирический герой, слова которого Вы произносите?
Что входит в его служебные обязанности?
Ему подчинены разработчики?
Он отвечает за разработку?
Начальник группы разработки?
Руководитель проекта?
3 май 05, 14:26    [1513391]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3909
Simon
ну блин народ вы тут и понаписали:)

читаю и ржу:)

пусть мне кто-нибудь объяснит чем:
1. написание
select ole1, pole2 from table
лучше чем
select * from table
если в таблице всего два поля

Тем, что если какой-нибудь чувак спустя энцать лет решит добавить в эту таблицу еще одно поле, то прилога поотваливается в тех местах, где впринципе это поле роли не играет.
ЗЫ И не надо мне рассказывать, про то что структуру надо продумывать на десятилетия вперед и если спустя какое-то время пришлось что-то поменять, то кто-то му**к, раз это не предусмотрел.
3 май 05, 14:27    [1513396]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
Simon
Member

Откуда:
Сообщений: 974
2Apex:

и почему прога отвалится при добавлении еще одного поля (блобы и лобы не в счет)?
3 май 05, 15:13    [1513543]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
Калина
Member

Откуда: Moskau
Сообщений: 2649
SQL> create table tst(a number,b number);
Table created.
SQL> insert into tst values(1,1);
1 row created.
SQL> declare
  2  n1 number;
  3  n2 number;
  4  begin
  5  select * into n1,n2 from tst;
  6  end;
  7  /
PL/SQL procedure successfully completed.
SQL> alter table tst add (c number);
Table altered.
SQL> declare
  2  n1 number;
  3  n2 number;
  4  begin
  5  select * into n1,n2 from tst;
  6  end;
  7  /
select * into n1,n2 from tst;
                    *
ERROR at line 5:
ORA-06550: line 5, column 21:
PL/SQL: ORA-00947: not enough values
ORA-06550: line 5, column 1:
PL/SQL: SQL Statement ignored

Это для Simon
3 май 05, 15:24    [1513580]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
mmiу
Guest
лечится
SQL> declare
  2  --n1 number;
  3  --n2 number;
  4  n tst%rowtype;
  5  begin
  6  select * into n from tst;
  7  end;
  8  /
3 май 05, 15:53    [1513707]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
Калина
Member

Откуда: Moskau
Сообщений: 2649
И снова меняем код?
Помоему речь шла о работоспособности кода при добавлении полей
Еще так лечится
SQL> declare
  2  n1 number;
  3  n2 number;
  4  n3 number;
  5  begin
  6  select * into n1,n2,n3 from tst;
  7  end;
  8  /
только не о том речь
3 май 05, 16:00    [1513737]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
SQLap
Member [заблокирован]

Откуда:
Сообщений: 34063
mmiу
лечится
SQL> declare
  2  --n1 number;
  3  --n2 number;
  4  n tst%rowtype;
  5  begin
  6  select * into n from tst;
  7  end;
  8  /


Плюс замена во всем остальном коде n1 и n2 на n.a и n.b...))
3 май 05, 16:01    [1513744]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
mmiу
Guest
>Плюс замена во всем остальном коде n1 и n2 на n.a и n.b...

нет, ничего менять не придется если с самого начала делать по уму. Мы ведь не говорим о том как переделывать приложения, а о том, за что дрюкнуть разработчтка... За select * в сочетании с rowtype меня не дрюкнуть :-) Хоть чего добавляй в свою таблицу...
3 май 05, 16:07    [1513764]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
muller
Member

Откуда: Москва
Сообщений: 925
SQLap

Плюс замена во всем остальном коде n1 и n2 на n.a и n.b...))


лечить поздно. надо просто СРАЗУ писать код так, как предложил mmiу

а за код
Калина
SQL> declare
  2  n1 number;
  3  n2 number;
  4  n3 number;
  5  begin
  6  select * into n1,n2,n3 from tst;
  7  end;
  8  /


действительно, надо ставить к стенке.
3 май 05, 16:09    [1513776]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
Калина
Member

Откуда: Moskau
Сообщений: 2649
Аналогично будут проблемы в случае
SQL> create table tst(a number,b number);
Table created.
SQL> create index tst_indx on tst(a,b);
Index created.
В случае если для select a,b from tst - будет использоваться индекс (ну , с оговорками само собой)
то для select * from tst индекс не будет использоваться
3 май 05, 16:47    [1513939]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
Калина
Member

Откуда: Moskau
Сообщений: 2649
И вообще, совершенно непонятно, зачем такое нужно.
To muller
JOIN тоже надо делать как
select table1.*,table2.* from table1,table2 ?
Или надо думать, какие данные выбираются?
3 май 05, 16:49    [1513951]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
muller
Member

Откуда: Москва
Сообщений: 925
Калина
И вообще, совершенно непонятно, зачем такое нужно.

Разработчику -- разработчиково, админу -- админово.

Калина

To muller
JOIN тоже надо делать как
select table1.*,table2.* from table1,table2 ?
Или надо думать, какие данные выбираются?

Ответ на Ваш вопрос:
Полагаю, что надо думать, какие данные выбираются.
( а почему Вы об этом спросили? )
8))
3 май 05, 17:04    [1514009]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
Fucker
Member [заблокирован]

Откуда:
Сообщений: 1525
VikingSan
просто ситуация упрощена
а если
SELECT * FROM tab1 t1,tab2 t2... where ...
а ...
* в чистом виде по определению несовместима с from ..., ...
Может стоит более корректно описывать неупрощенные ситуации?
.dba
AI
Я бы увольнял любого админа, не дающего разработчикам доступ на файлы трассировки (10046/10053...). Заодно и на некоторые представления словаря вроде v$sesstat.
Хм... Где-бы еще найти таких разработчиков, которым было бы интересно в трейсфайлах копаться.
Это уже вопрос к HR Managers, где, как и каких работников им искать. Разработчик обязан уметь пользоваться трассировкой, а админ обеспечить ему эту возможность.

use-se
Scott Tiger
Девелоперу должно быть сложно и неуютно, а девелоперская БД должна жить на максимально тормозной машине, что способствует написанию быстро работающего кода.

Не согласен на все 100%.
1. Это (ИМХО: ложное), не обоснованное предположение. Если следовать этой логике, то все что разрабатывается на слабых тестовых серверах будет работать на УРА и, наоборот. Качество программного кода (ИМХО) исключительно зависит от квалификации разработчика и его ресурсах (временной ресурс, финансовый ресурс - зарплата и т.п.). Сознательно ставя разработчика в тяжелые условия труда, Вы тем самым сознательно урезаете его временной ресурс.
Разработка может вестись на чем угодно, главное, чтобы на всех этапах работы над системой люди имели четкие требования, которым должно удовлетворять их творение. В том числе и по быстродействию.

Возможно Scott Tiger немного перегнул палку, специально сажать разработку на "самую тормознутую машину" не стоит.

Просто слишком часто в жизни встречаются ситуации, когда разработчики ведут разработку в "тепличной" обстановке при отсутствии какой-либо нагрузки на сервер, при отсутствии конкурентного доступа к данным и совершенно не учитывают реальные условия эксплуатации системы. Видимо это и было основанием его мнения.

use-se
3. Как правило если разработчик имеет какие либо ограничения к минимальной конфигурации, то он автоматически урезает уровень сервиса для заказчика. В результате заказчик получает "немного не то, что заказал".
Есть понятие "заказанной и утвержденной клиентом функциональности", есть приемка клиентом заказанного функционала.
use-se
Что касается дополнительных привелегий, фраза: "Аналогично и поднятые привилегии на девелоперской базе способствуют написанию кода, который невозможно поставить в production".
Никаких проблем, все эти ошибки тут же проявятся при разворачивании кода на тестовом сервере, куда разработчик не имеет доступа. Отвечающий за выход релизов первым закричит, настучит по башке такому разработчику и не пропустит такой код.
use-se
Освещается в этом топике только с одной стороны. Большинство разработчиков работают по схеме с 2-мя, 3-мя аккаунтами:
Первый: разработчик - непосредственная реализация бизнес-логики приложения. Здесь не используются какие либо дополнительные привелегии, за исключением тех, которые нужны для различного рода инструментария;
Второй: пользователь - используется исключительно для тестирования;
Третий: ДБА. Этот аккаунт нужен для иследования отдельных моментов. ПОД НИМ РАЗРАБОТЧИК НЕ РАБОТАЕТ И НЕ СТРОИТ БИЗНЕС-ЛОГИКУ.
Какая-то каша получается. И почему именно 2 или 3, а не больше или меньше? Что такое "пользователь - используется исключительно для тестирования"?.. Т.е. у него все работает, а у всех остальных с другими полномочиями не будет?

to all
По поводу всех остальных пунктов вроде dynamic sql, autonomous, etc...
и чувства меры. Надо просто хорошо знать инструмент (Oracle & tools) и уметь его использовать, когда это действительно надо и так, как это надо.

Практически все ответы на свои вопросы вы найдете в Concepts и многочисленных Application Developer's Guide.

Fucker

PS: Интересно, к чему приведет четкое, формальное и бездумное применение подобных "формальных списков смертных грехов разработчиков"...
3 май 05, 17:12    [1514033]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
Калина
Member

Откуда: Moskau
Сообщений: 2649
muller
Калина
И вообще, совершенно непонятно, зачем такое нужно.

Разработчику -- разработчиково, админу -- админово.

Калина

To muller
JOIN тоже надо делать как
select table1.*,table2.* from table1,table2 ?
Или надо думать, какие данные выбираются?

Ответ на Ваш вопрос:
Полагаю, что надо думать, какие данные выбираются.
( а почему Вы об этом спросили? )
8))

Потому, что выбирать лишние данные незачем, уже говорилось, что планы могут изменяться. Тут совершенно ни при чем разработчик ты или админ.
3 май 05, 17:19    [1514063]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
muller
Member

Откуда: Москва
Сообщений: 925
Калина
Потому, что выбирать лишние данные незачем, уже говорилось, что планы могут изменяться. Тут совершенно ни при чем разработчик ты или админ.

резон есть.
Некрые "мои" куски без select * не обойдутся ( там приклад работает со строкой ), а в некрых и правда можно ( а может и стоило бы ) подчистить...
Спасибо.
3 май 05, 18:23    [1514255]     Ответить | Цитировать Сообщить модератору
 Re: Админы! за что вы убивали бы разработчиков?  [new]
Калина
Member

Откуда: Moskau
Сообщений: 2649
Никто и не говорил, что * ненадо использовать, но тот код, который я привел- я наблюдал , не дословно конечно, но суть такая.
Я не рассматривал клиентские приложения , я продемонстрировал, как я при модификации некой базы, ролучил половину пакетов в нерабочем состоянии.
Разобраться при этом в возникающих проблема очень сложно, мне кажется, что гораздо легче перечислить поля, тем более, что если о каких-то полях мы незнаем на этапе написания кода, то и использовать их не можем, зачем их вообще читать?
P.S. Я из девелоперов пришел, 7 лет писал , так что это не только мое ,админово, мнение.
3 май 05, 23:21    [1514657]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 21   вперед  Ctrl
Все форумы / Oracle Ответить