Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2011.11.20;
Скачать: [xml.tar.bz2];

Вниз

Что учить?   Найти похожие ветки 

 
oxffff ©   (2011-07-22 13:40) [120]


> DiamondShark ©   (22.07.11 12:53) [115]
>
> >  Но менять что то не приветствуется совершенно. Только
> добавлять.
>
> Менять таблицу -- большой шанс поломать существующий код.
>
> Вполне возможно, что такая политика весьма оправдана. И
> даже подкреплена набитыми шишками.



> tesseract ©   (22.07.11 13:18) [116]
>
> >  Но менять что то не приветствуется совершенно.
>
>
> Ессно. Будет крайне весело если по данным из этой бд сдавались
> отчеты. А теперь переделывать  - задним число полетит логика.
>
>
>


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

Ну а логика растет и растет, по бокам, по болотам идет.
И кричит программист гав..у, я больше так не могу.....
И заплакали ...., не лучше ли рефакториться.


 
tesseract ©   (2011-07-22 13:48) [121]


> И заплакали ...., не лучше ли рефакториться.


ВыполнитьОбработку("Проведение",Метаданные.Имя(),ДатаДокумента);

Вот так спасаемся.


 
Кщд   (2011-07-22 14:30) [122]

>oxffff ©   (22.07.11 13:40) [120]
>И кричит программист гав..у, я больше так не могу.....
>И заплакали ...., не лучше ли рефакториться.
качественный рефакторинг(а не замена древнего г. новым) требует хороших специалистов, при этом с глубоким знанием предметной области, а это деньги - и немалые.
весьма трудно донести до бизнеса необходимость финансовых вливаний в такое мероприятие, как рефакторинг, ибо: "Зачем менять? Оно же работает!"
поэтому проще(а в случае огромных, разросшихся систем домамонтового периода - дешевле) держать на поддержке штат низкооплачиваемых специалистов, которые "штопают" расползающееся г., преумножая его, конечно.


 
oxffff ©   (2011-07-22 14:35) [123]


> Кщд   (22.07.11 14:30) [122]


Это реальность.


 
euru ©   (2011-07-22 14:43) [124]


> И. Павел ©   (22.07.11 10:50) [85]
> Просто встречал много SAP программистов, считающихся неплохими
> в своей сфере, которые удивляли меня вопросами типа "разве
> NULL чем-то отличается от ""?" и т.д.

В АВАРе нет понятия NULL. И поэтому, если SAP специалист знает только этот язык, такой вопрос с его стороны естественен.


 
oxffff ©   (2011-07-22 15:06) [125]


> euru ©   (22.07.11 14:43) [124]


Читаю про SAP BI.
BW 310, 305,306.

Вечером прихожу, включаю Delphi и обнимаю ее.


 
oxffff ©   (2011-07-22 15:28) [126]


> euru ©   (22.07.11 14:43) [124]
>
> > И. Павел ©   (22.07.11 10:50) [85]
> > Просто встречал много SAP программистов, считающихся неплохими
>
> > в своей сфере, которые удивляли меня вопросами типа "разве
>
> > NULL чем-то отличается от ""?" и т.д.
>
> В АВАРе нет понятия NULL.


Есть. IS [NOT] NULL addition для select в OPEN SQL.


 
MonoLife ©   (2011-07-22 15:47) [127]


> 33 Простые буковки, а насколько сложен язык и еще более
> сложны поделки

а ноток всего 7 и "древние" делали из них шедевры:)

Хочу учиться у Sergey Masloff , тем более, он настаивает:)
Эх.. если б в моей юности были такие учителя как sniknik, Ю.Зотов и многие из завсегдатаев этого форума, небыл б я щас таким неучем..:)
с 2002 занимаюсь Делфи и с каждым годом мне кажется, что я знаю все меньше и меньше..


 
tesseract ©   (2011-07-22 15:52) [128]


> В АВАРе нет понятия NULL.


есть unassigned или emtyreference значить.


 
euru ©   (2011-07-22 16:26) [129]


> oxffff ©   (22.07.11 15:28) [126]
> Есть. IS [NOT] NULL addition для select в OPEN SQL.

1. Это всего лишь addition для select. Сам язык таким понятием не оперирует.
2. Этот addition фактически актуален только для Native SQL. Для Open SQL выражение поле IS NULL можно заменить на поле = SPACE, потому что в любом случае значения полей, содержащих NULL, преобразуются в начальные значения, соответствующие типу этих полей.


> tesseract ©   (22.07.11 15:52) [128]
> есть unassigned или emtyreference значить

IS ASSIGNED (а также IS BOUND) - это состояние объекта данных, а не его значение.


 
tesseract ©   (2011-07-22 17:12) [130]


> IS ASSIGNED (а также IS BOUND) - это состояние объекта данных,
>  а не его значение.


Ну отладчик его знает как у вас в ABAP называется пустое и не связанное поле. У нас в ссылочных типах это фактически разные значения. NULL - не создан  мета-объект, EmtyReference - пустая ссылка. Различия на уровне операций языка.


 
oxffff ©   (2011-07-22 17:31) [131]


> euru ©   (22.07.11 16:26) [129]
>
> > oxffff ©   (22.07.11 15:28) [126]
> > Есть. IS [NOT] NULL addition для select в OPEN SQL.
>
> 1. Это всего лишь addition для select. Сам язык таким понятием
> не оперирует.
> 2. Этот addition фактически актуален только для Native SQL.
>  Для Open SQL выражение поле IS NULL можно заменить на поле
> = SPACE, потому что в любом случае значения полей, содержащих
> NULL, преобразуются в начальные значения, соответствующие
> типу этих полей


Не совсем.
Насколько помню приходилось мне писать запрос только пришлось использовать не IS NULL, а именно = "        "  в запросе при проверки сторно. Так что обертка все таки подставляет IS NULL.


 
oxffff ©   (2011-07-22 17:31) [132]


> Так что обертка все таки подставляет IS NULL.


при where .. IS NULL


 
Sergey Masloff   (2011-07-22 17:56) [133]


> MonoLife ©   (22.07.11 15:47) [127]
>
> Хочу учиться у Sergey Masloff , тем более, он настаивает:
> )

А денег сколько хочешь на время учебы? Пиши на почту ;-) Можем устроить обучение


 
картман_   (2011-07-22 18:11) [134]


> с 2002 занимаюсь Делфи и с каждым годом мне кажется, что
> я знаю все меньше и меньше..

(с) забыл


 
MonoLife ©   (2011-07-22 19:21) [135]


> А денег сколько хочешь на время учебы?

в смысле, сколько стоит обучение? Дорого берете?:)

> (с) забыл

склероз, батенька(с)
:)


 
Студент   (2011-07-22 19:35) [136]

----------------------------------------------------------------------------------
SQL? OMG.

> Герман

Тебе надо выучить ещё что-нибудь, кроме албанского. Угу.


 
Студент   (2011-07-22 19:41) [137]


> sniknik ©


Да, ВЫ правы.
Всякие треи, хаки - это конечно хорошо, но НУЖНОГО нет.
Что составляет это НУЖНОЕ?


 
Loginov Dmitry ©   (2011-07-22 20:01) [138]


> Почему именно Left? Там и другие слова есть )
>
> {INNER | {LEFT | RIGHT | FULL} OUTER | CROSS } JOIN


На деле их меньше
1) INNER JOIN (INNER можно опустить). Вместо INNER JOIN можно использовать WHERE.
2) LEFT OUTER JOIN (с RIGHT - то же самое, но ведущая таблица указывается после ведомой).  OUTER можно опустить.
И варианты с FULL и CROSS, имеющие больше академическую значимость, хотя в каких-то практических задачах безусловно используются.


 
Loginov Dmitry ©   (2011-07-22 20:25) [139]


> >Но учти, если есть выбор, то лучше применять LEFT JOIN
> это, простите, высококонцентрированная ахинея
> не учите дурному


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


> А потом Where добивать условия что ли? JOIN он хитёр и опасен.


> И получают такие чудеса запросов как LEFT JOIN on a.id=b.id WHERE b.id <>NULL


К моменту выбора между JOIN и LEFT JOIN необходимо подходить осознанно. Никаких особых хитростей в них разумеется нет, а вот опасности есть и связаны они с непониманием логики их работы. Незачем использовать LEFT JOIN только лишь для того, что сымитировать JOIN. Но и о проблемах с INNER JOIN не следует забывать. Ведущая и ведомая таблица могут поменяться местами неожиданно и вчерашний супербыстрый запрос завтра может оказаться тормозом для всей системы. В этом плане LEFT JOIN является намного более предсказуемым, однако требует от программиста выполнения некоторых функций оптимизатора.


 
Игорь Шевченко ©   (2011-07-22 21:11) [140]

Loginov Dmitry ©   (22.07.11 20:25) [139]

Дело Архангельского живет и побеждает


 
Loginov Dmitry ©   (2011-07-22 22:14) [141]

Сказать по теме больше нечего? Напомни хотя бы, в чем суть "Дела Архангельского".


 
Anatoly Podgoretsky ©   (2011-07-22 22:34) [142]

> Loginov Dmitry  (22.07.2011 22:14:21)  [141]

Архангельский много сделал для компьютерной науки, но лучше бы не делал.


 
Loginov Dmitry ©   (2011-07-22 23:37) [143]

Анатолий, спасибо, получилось понятно и сдержанно, есть даже элементы конкретики.
Тогда вопрос Игорю. Причем здесь "Дело Архангельского"? Был задан простой вопрос: в чем отличие INNER JOIN и LEFT JOIN. Я постарался объяснить суть отличия. Я понимаю, что каждый знает SQL по разному, кто-то использует преимущественно INNER JOIN, кто-то LEFT JOIN, кто-то соединение в WHERE, кто-то разруливает вложенными запросами, кто-то же считает наивысшим мастерством умение обработать результаты простейшего SELECT-запроса на стороне клиента. Все люди разные, опыт у всех разный. И здесь никто никого не заставляет менять излюбленный подход. Я объяснил совершенно очевидные вещи. Вовсе я их придумывал, в литературе все есть. Какие-то моменты прокомментировал от себя (но опять же - не придумывал). Скромный пятилетний опыт практической (почти каждодневной) работы с SQL дает хоть какое-то моральное право на это. Надеюсь быть правильно понятым. Не хочется засорять форум и тратить свое и тем более чужое время на столь бесполезные рассуждения.


 
Игорь Шевченко ©   (2011-07-22 23:47) [144]

Loginov Dmitry ©   (22.07.11 23:37) [143]


> Причем здесь "Дело Архангельского"?


Ответ дан в [63], даже не мной.
Могу процитировать, если лень лезть в указанный пост: "Не учите дурному"

Один в один ситуация с Архангельским


 
Германн ©   (2011-07-23 01:02) [145]


> Студент   (22.07.11 19:35) [136]
>
> --------------------------------------------------------
> --------------------------
> SQL? OMG.
>
> > Герман
>
> Тебе надо выучить ещё что-нибудь, кроме албанского. Угу.
>

Да я и албанского не знаю. :(
А "нахвататься" поверхностных" знаний о различных языках программирования - пустая трата времени. При собеседовании на любой "средней" фирме вас отсеют!


 
Anatoly Podgoretsky ©   (2011-07-23 08:27) [146]


> Loginov Dmitry ©   (22.07.11 23:37) [143]

Применение должно диктоваться только бизнес логикой, а не предпочтениеми.


 
Loginov Dmitry ©   (2011-07-23 10:01) [147]


> Ответ дан в [63], даже не мной.
> Могу процитировать, если лень лезть в указанный пост: "Не
> учите дурному"
>
> Один в один ситуация с Архангельским


Ясно все с Вами! Лень лезть, лень объяснять... Гораздо проще вот так отписаться.


> Применение должно диктоваться только бизнес логикой


Бизнес-логика не оперирует специфичными для SQL (или даже для СУБД) понятиями "ведущая" и "ведомая" таблица и не отменяет предпочтения.


 
Anatoly Podgoretsky ©   (2011-07-23 10:13) [148]

> Loginov Dmitry  (23.07.2011 10:01:27)  [147]

Архангельского все знаю, объяснения излишни.


 
sniknik ©   (2011-07-23 10:14) [149]

> Бизнес-логика не оперирует специфичными для SQL (или даже для СУБД) понятиями "ведущая" и "ведомая" таблица и не отменяет предпочтения.
а ты не путаешь left и right join? что в принципе одно и тоже, только меняет сторону что к чему присоединять. вот тут возможны предпочтения, как левши или правши у людей, делают тоже но разными руками. (и кому как удобнее предствлять... мне например то что "главная" слева, и если я ее первой в скрипте пишу, значит она слева... хотя могут быть на разных строчках и "левая" написана правее)

но говоришь то ты про left и inner, по обсуждению, а не left и right. и это вообще не одно и тоже.

ну типа, аналогия, можно говорить, "я предпочитаю ездить на работу на метро"... а не автобусом. (одно и тоже разными маршрутами). а ты говоришь "я предпочитаю ездить в пивбар"... ??? что значит в пивбар? нужно то на работу, и ты не бармен.


 
Loginov Dmitry ©   (2011-07-23 10:32) [150]


> но говоришь то ты про left и inner, по обсуждению, а не
> left и right. и это вообще не одно и тоже.


Еще раз хотелось бы повторить. Все люди разные. Опыт работы с SQL у всех разный. Привычки разные. Кто-то привык использовать INNER JOIN, а другой и знать о нем не знает, но пользуется LEFT JOIN (или же предпочитает слово RIGHT, а что поделаешь, LEFT / RIGHT - "политика", однако ;). А третий умудряется выкручиваться вложенным SELECT и по сих пор ему это удается. И все трое зарабатывают своими, пусть разными знаниями и привычками, совершенно реальные деньги, а кто-то и в пивбар еще успевает ;)


 
sniknik ©   (2011-07-23 10:52) [151]

понятно, это типа научился кувалдой махать и ну давай ей мебель собирать, и вообще все делать пока удается. а когда говорят "там же шурупы, их не забивать, их отверткой завинчивать нужно", отвечаете "а это у меня такое предпочтение. и ведь собираю! а требования у вас при приеме на работу завышенные, и вообще парень я хороший, разбирающийся, привычки только не те что вам нужно. вы бы меня взяли, я вот тут смотрите, что умею - в заборах дырки вертеть, "хак" называется (это круто и поэтому зарплата должна быть высокая), и объяснили наглядно как надо... а я вам пока всю мебель по испорчу, но это же не со зла, это я так привык.".

p.s. это не к тебе лично, это у меня общее впечатление от ветки.


 
Anatoly Podgoretsky ©   (2011-07-23 11:23) [152]

> Loginov Dmitry  (23.07.2011 10:32:30)  [150]

У inner и outer, даже результаты разные по количеству записей


 
_Юрий   (2011-07-23 11:25) [153]

Архангельский умер.


 
Anatoly Podgoretsky ©   (2011-07-23 11:28) [154]

> _Юрий  (23.07.2011 11:25:33)  [153]

Но дело его живет.


 
Loginov Dmitry ©   (2011-07-23 11:43) [155]


> sniknik ©   (23.07.11 10:52) [151]


:)))))))
Спасибо, повеселил ;)


> Anatoly Podgoretsky ©   (23.07.11 11:23) [152]


Анатолий, сам же недавно приводил пример, в котором LEFT JOIN имитирует работу JOIN (с дополнительным WHERE)! :)


 
sniknik ©   (2011-07-23 12:11) [156]

> Анатолий, сам же недавно приводил пример, в котором LEFT JOIN имитирует работу JOIN (с дополнительным WHERE)! :)
это все одно что забить на две трети шуруп кувалдой, а после довернуть отверткой...
вред не так заметен, не критичен. но все одно не правильно, качество страдает. (он в этом смысле его и приводил)


 
Anatoly Podgoretsky ©   (2011-07-23 13:32) [157]

> Loginov Dmitry  (23.07.2011 11:43:35)  [155]

Я приводил пример как пример дурости. Как пример ламеризма.


 
MsGuns ©   (2011-07-23 14:09) [158]

>Loginov Dmitry ©   (23.07.11 11:43) [155]

Ваша ошибка в том, что Вы свой опыт, пусть и немалый (на Ваш взгляд), но СВОЙ пытаетесь обобщать на такую весьма многоликую, если не сказать абстрактную вещь как сиквель. И с этих позиций давать рекомендации "вселенского масштаба". И дело даже не в том, что Вы мешаете в кучу две разные по смыслу кляузы Inner и left, а в том, что делаете это навязчиво, заранее направляя  "читателей" по неверному (во всяком случае далеко не самому верному) пути.
Вот в этом, как мне кажется, и Ваше несомненное сходство с пресловутым Архангельским


 
Loginov Dmitry ©   (2011-07-23 15:07) [159]

Сергей, спасибо! Именно такой ответ я и ждал. Но почему-то добиться его было весьма сложно, ведь гораздо проще написать: "не прав ты, потому что несешь ахинею", чем высказать более-менее обоснованную критику.

Разумеется, при составлении своего сообщения [41], я ожидал подобной реакции, хотя рассчитывал на более грамотную критику. Кстати, почему то никто не обратил внимание, что в [41] рекомендация "вселенского масштаба" начинается с фразы "но учти, если есть выбор...". Т.е. рассматриваются только те случаи, в которых есть выбор, т.е. результат работы обоих подходов окажется идентичным. И дается простейший пример, и для данного примера описываются преимущества и недостатки обоих подходов.
Как мне представляется, здесь имеет место излишняя драматизация. Но это лишь мое скромное мнение, поскольку настоящего опыта в преподавании SQL у меня нет, а ведь это действительно очень важный этап, в ходе которого можно направить человека на путь истинный или сбить его с этого пути.


> Вы свой опыт, пусть и немалый (на Ваш взгляд)


Я не являют специалистом в области баз данных. Это не является моим основным направлением, пусть даже с базами данных и SQL приходится иметь дело практически ежедневно на протяжении последних 5 лет. Поэтому нельзя объективно оценивать опыт.


> Вот в этом, как мне кажется, и Ваше несомненное сходство
> с пресловутым Архангельским


Пресловутый Архангельский, Ф... Вы когда-нибудь писали  технические книги подобного объема? Скорее всего нет, иначе бы были другого мнения. Это огромнейший труд, достойный глубокого уважения, пусть даже не без досадных промахов. И зачастую труд - неблагодарный. Время на него уходит - годы, а вознаграждения зачастую копеечные.


 
MsGuns ©   (2011-07-23 15:52) [160]

>Пресловутый Архангельский, Ф... Вы когда-нибудь писали  технические >книги подобного объема? Скорее всего нет, иначе бы были другого мнения. >Это огромнейший труд, достойный глубокого уважения, пусть даже не без >досадных промахов. И зачастую труд - неблагодарный. Время на него >уходит - годы, а вознаграждения зачастую копеечные.

Вы что, серьезно убуждены, что все, что находится внутри книжек Архангельского, писано (именно писано, а не скопировано) Архангельским ?

Кроме того.. по-моему Чехова однажды спросил один молодой литератор, стОит ли начинать писать книгу. На что великий писатель сказал что-то вроде "Если можете НЕ писать, не пишите !"

С вредом, нанесенным книжками этого и других подобных "писателей", приходится сталкиваться на каждом шагу. Особенно если говорить о студентах и выпускниках ВУЗов и колледжей, которых в подавляющем большинстве учат горе-преподы на книжках именно этого автора.

А по-поводу "огромного неблагодарного труда"... Когда мне таксист (к примеру) начинает рассказывать как тяжел и неприбылен его труд, я улыбаюсь и советую ему итти на завод слесарем или в дворники. Сразу замолкает.. Было бы хреново, не "таксил" бы :)



Страницы: 1 2 3 4 5 6 вся ветка

Форум: "Прочее";
Текущий архив: 2011.11.20;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.84 MB
Время: 0.021 c
15-1311625800
Юрий
2011-07-26 00:30
2011.11.20
С днем рождения ! 26 июля 2011 вторник


2-1312103335
Pepe
2011-07-31 13:08
2011.11.20
Перевод из C++


2-1311696047
prodex
2011-07-26 20:00
2011.11.20
RasDial возвращает ошибку 668


3-1266498498
Den
2010-02-18 16:08
2011.11.20
Буквы Е и Ё. Контекстный поиск


2-1311930662
From4pda
2011-07-29 13:11
2011.11.20
копирование файлов





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский