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

Вниз

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

 
Студент   (2011-07-21 23:25) [40]


> 65535   (21.07.11 23:10) [34]


С динамическими методами не особо работал.


> Сергей М. ©   (21.07.11 23:16) [36]


> А для обоснованных заявлений "знаю Дельфи" вряд ли и пол-
> жизни хватит)


Ну тогда как я должен был написать?
"Не знаю Дельфи"?
"Знаю, но немножко"?
"Знаю, вроде бы"?
"Знаю 3 года тока"?
"Знаю, а ты?"?


 
Loginov Dmitry ©   (2011-07-21 23:26) [41]


> но они говоря, что знают (объявление было именно по sql)
> не знали разницы между inner и left join ... даже своими
> словами никто не сказал (правильно), что произойдет в примере.
>


Разумеется. Не удивлюсь, что и про "join" (как ключевое слово в SQL) в первый раз услышали. Будет уже хорошо, если продемонстрируют соединение пары таблиц с помощью where. Но и этого достаточно в условиях, когда есть кому научить, показать. Важно, чтобы в подопытных базах были таблицы, содержащие не меньше сотни тысяч строк. Ставится несложная задача. Соискатель "умело" ее решает (ну как умеет), результат правильный, но запрос будет выполняться несколько часов. Затем вы пишите аналогичный запрос. Разумеется он работает не более секунды. На соискателя такое "шоу" может подействовать весьма эффективно и он начнет относится к SQL более серьезно.


> пример был на апдейт одной таблицы значением из другой,
> и вот что будет с записями которые не подходят под условие
> объединения в апдейте в обоих случаях?


Заинтриговал, а где сам пример? :)


> inner left в чем разница то своими словами ? :)
> на практике обычно только leftиспользую.


Уже объяснили.
Если хочешь иметь в результате запроса все записи из ведущей таблицы, то делай LEFT JOIN. Если же нужны только те записи, информация по которым есть в обеих таблицах, то используй INNER JOIN (или более коротко - "JOIN", или связь таблиц через WHERE, что действует аналогично). Но учти, если есть выбор, то лучше применять LEFT JOIN (на практике LEFT JOIN приходится применять гораздо чаще, чем JOIN). Дело в том, что время выполнения запроса получается более предсказуемым, поскольку составление плана запроса - всегда однозначное. А вот если использовать "внутреннее" соединение (явное или неявное), то план запроса составляется автоматически, при этом используется собранная по индексам статистика. Статистика штука не безгрешная, может наврать. Объясню проще. Есть 2 таблицы: справочная (1000 записей) и оперативная (1000000 записей). Разумеется ведущей таблицей в большинстве случаев должна быть оперативная. Если мы сделаем иначе, то рискуем получить жесточайшие тормоза. Если доверимся JOIN, то вероятнее всего в качестве ведущей будет выбрана оперативная таблица с миллионом записей. Однако, в результате активной работы с БД статистика может оказаться неактуальной, в результате чего справочная таблица окажется выбранной в качестве ведущей. Разумеется, статистика - далеко не единственный критерий, диктующий оптимизатору план запроса.
В некоторых случаях без JOIN не обойтись. Например для FIREBIRD использование JOIN в комбинации со сложными вложенными запросами приводит к тому, что сначала выполняются все эти запросы, их результат помещается в кэш (в ОЗУ или на диске), а при дальнейшем соединении используются уже результаты из кэша. LEFT JOIN в подобных ситуациях не поможет.


 
Loginov Dmitry ©   (2011-07-21 23:30) [42]


> Ну тогда как я должен был написать?


Для работодателя пиши, что ты - ас. Потом все равно будет видно. Встречают по одежке.


 
картман ©   (2011-07-21 23:33) [43]


> Loginov Dmitry ©   (21.07.11 23:26) [41]


>
> Заинтриговал, а где сам пример? :)


опять не заметил


 
Loginov Dmitry ©   (2011-07-21 23:34) [44]


> P.S. Этой мой стандартный вопрос по Delphi.


Заранее отсеиваешь конкурентов? :)
Какие еще страшные слова знаешь?


 
65535   (2011-07-21 23:39) [45]


> Kerk ©   (21.07.11 23:17) [37]
>
> > 65535   (21.07.11 23:10) [34]
> >
> > > Студент   (21.07.11 23:03) [31]
> > >
> > > > 65535   (21.07.11 22:46) [26]
> > >
> > > > Скажите а в чем отличие динамических методов от виртуальных.
>
>
> > > В скорости.
> >
> > Чем отличаются механизмы. Преимущества и недостатки.
> >
> > P.S. Этой мой стандартный вопрос по Delphi.
>
> Тебе в работе хоть раз пригодился ответ на этот твой стандартный
> вопрос? Часто динамические методы используешь? Я даже по-
> другому спрошу - после выхода фильма "Терминатор 2" ты их
> хоть раз использовал?


Использовал в качестве усовершенствования GOF visitor


 
65535   (2011-07-21 23:41) [46]


> Loginov Dmitry ©   (21.07.11 23:34) [44]
>
> > P.S. Этой мой стандартный вопрос по Delphi.
>
>
> Заранее отсеиваешь конкурентов? :)
> Какие еще страшные слова знаешь?
>
>


oxffff


 
sniknik ©   (2011-07-21 23:58) [47]

> Человек, нормально владеющий SQL, "на вырост" за три копейки не пойдет.
не учите меня жить, лучше помогите материально...
ну вот откуда такое стремление поучать ничего не зная про ситуацию...? и где написано, что "нормально владеющий", и почему решил, что "три копейки".

нормальную зарплату предлагали, для требуемого уровня. и уровень не "hi-end спец", просто "на должном", чуть выше чем "хело ворд" в селекте...
или думаешь объединения в sql это что-то заоблачное, недоступное простым смертным? блин, да это просто показатель работал человек с ним, хотя бы месяц два, или просто перед собеседованием брошюрку полистал.

> Вот это и умею чуток.
ну, а чего, ты не исключение, говорю же ВСЕ такие. а потом плачутся по форумам - "куда нам без опыта работы приткнуться" (была вроде недавно подобная ветка? нет?).
а вас может и взяли бы, если бы вы не "понты кидали", а учили полезное для работы, так чтобы быстро могли хоть что-то делать, и учится новому уже в процессе.  а вот эти хаки/треи это все одно, что с 0, да еще и портят программистов ... у них же от сих "тайных знаний" ЧСВ раздуто, типа крутые хакеры, и запросы от этого под потолок, а на деле, для работы полные нули, с соответствующим к ним отношением/предложением зарплаты, да и то если возьмут.  мы вот не взяли, не нашли подходящего "молодого", взяли с опытом... так у этого с опытом, знающего, к тому же запросы по зарплате меньше чем у некоторый "нулевых хакеров" ;(.


 
sniknik ©   (2011-07-22 00:00) [48]

> Заинтриговал, а где сам пример? :)
в BOL


 
Kerk ©   (2011-07-22 00:04) [49]


> sniknik ©   (21.07.11 23:58) [47]
>
> > Человек, нормально владеющий SQL, "на вырост" за три копейки
> не пойдет.
> не учите меня жить, лучше помогите материально...
> ну вот откуда такое стремление поучать ничего не зная про
> ситуацию...?

Потому что ситуация типичная. Сам же говоришь, что в итоге никого не нашли. И дело конечно же не в вас, а в том, что на рынке труда нет адекватных начинающих. Дададада.


 
Kerk ©   (2011-07-22 00:06) [50]


> 65535   (21.07.11 23:39) [45]
>
> Использовал в качестве усовершенствования GOF visitor

Целый один раз? Круто. Сразу видно, что очень полезный типовой вопрос для собеседования.

Расскажи, кстати, почему именно динамический метод в той ситуации использовал. Интересно.


 
sniknik ©   (2011-07-22 00:14) [51]

> Уже объяснили.
мне вообще то не требуется объяснений... тем более так много бакаф... про краткость поговорку слышал?

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


 
Rouse_ ©   (2011-07-22 00:16) [52]


> Тогда уже особенности накручивания механизмов защиты.
> И т.д. вплоть до  побитовое описание дескрипторов в таблицах
> IDT, LDT, GDT.

Серег, ну блин - этож переусложнение первоначального вопроса :)


> Делфиец   (21.07.11 23:17) [38]
> Обычно такое спрашивают и в этот момент ипытывают эктаз
> и думают

Хм, сурово... Даже сам офигел от такой постановки :)
Вообще-то это азы в данной области, ну типа таблицы умножения в математике...


 
Kerk ©   (2011-07-22 00:25) [53]


> Rouse_ ©   (22.07.11 00:16) [52]
> Хм, сурово... Даже сам офигел от такой постановки :)
> Вообще-то это азы в данной области, ну типа таблицы умножения
> в математике...

Вот как раз по этим вопросам, имхо, проще молодежь найти. Все ж с детства хотят быть космонавтами, пожарными или мафиози. Хакерами или инженерами Гугла накрайняк. Но никто не хочет до пенсии обслуживать толстых теток из бухгалтерии. Это и объясняет определенный сдвиг сферы интересов студентов.

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


 
Kerk ©   (2011-07-22 00:27) [54]

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


 
Rouse_ ©   (2011-07-22 00:30) [55]

Молодежь найти просто, но чтоб она еще нюансы ловила (оть кстати хорошо показано):
http://www.youtube.com/watch?v=LsYuqwD5a2g&feature=related


 
sniknik ©   (2011-07-22 00:47) [56]

> - это крайний неадекват.
ты опять судишь, и опять однобоко, не зная ситуации/придумывая то чего нет...

собеседование это не экзамен на вступление в вуз для дальнейшего обучения, это прием на работу...  учить его согласны, и это даже прописано в объявлении, но никто не будет только учить, без выполнения им работы. типа учись, получай зарплаты (высокую, т.к. знает бесполезные треи, хуки, и потому с запросами пришел уже огогооо...) а где нибудь через полгодика год начнешь выполнять работу...
нет, такого не будет! берут работать. sql это самое простое, из связанного, что  можно предложить, и нужно прямо сейчас. хотя, в принципе нам еще уборщица нужна... если согласен, тогда можно ВООБЩЕ ничего по программированию не знать, и учится в процессе. но и зарплата пониже будет.
доступно?

а уж когда тип написавший резюме sql, и идущий на объявление по sql, "вдруг" его не знает, вот тут уже и выясняется "ну а вообще чего знаешь?" про хуки/хаки/треи, но это даже не проверяется, т.что говорить, что он разобрался..., вряд ли, не буду, да и пофигу ЭТО НЕ НУЖНО, и не собирался никто спрашивать/проверять. т.что ладно, что соврал про sql, поверим что про хуки не врет, но все одно всплывает это уже после отказа, или уже при решении отказать, но просто вот беседу не полуслове не прерывать.


 
Германн ©   (2011-07-22 00:53) [57]


> хочется выучиться ещё какой-нибудь язык

Советую выучить английский, китайский, немецкий и французский.


 
Kerk ©   (2011-07-22 01:08) [58]


> sniknik ©   (22.07.11 00:47) [56]

Ну я ж говорю - требуется оператор клавиатуры со знанием SQL. Программированием тут и не пахнет.


 
Sergey Masloff   (2011-07-22 06:10) [59]

sniknik ©   (21.07.11 23:58) [47]
> или думаешь объединения в sql это что-то заоблачное, недоступное >простым смертным? блин, да это просто показатель работал человек с ним, >хотя бы месяц два, или просто перед собеседованием брошюрку полистал.
Я тебя сначала не понял думал наоборот ты считаешь SQL чем-то заоблачным ;-) Хотел возразить.

 На самом деле SQL очень логичный и простой язык, на его изучение нужно месяц максимум два, и еще 2-3 месяца на изучение фич специфичного сервера в процессе работы. За это время я лично готов выдрессировать SQL-гуру из любого человека имеющего голову на плечах ;-)
 ИМХО по сложности это просто несопоставимо с двиганьем лотка в разные стороны на уровне владения этим делом например, Розыча.


 
Дмитрий С ©   (2011-07-22 06:43) [60]

спасибо, что разъяснили про join. А не вопросы про трюки разные не задаете?
Или, например, вопрос на уверенность: как будет вести себя запрос, если для join не указать секцию on :)

А по поводу виртуальных и динамических методов. По сути одно и то же, только первое оптимизировано на скорость, второе на размер кода.
Виртуальный метод при вызове обращается в таблице виртуальных методов, которая заполняется при создании объекта (или инициализации класса). Как динамические работают я не знаю.

По поводу статических и динамических библиотек. Первые загружаются при запуске программы, функции вызываются через таблицу импорта. Вторые в ходе работы программы, функции вызываются через указатели, полученные через GetProcAddress. Обычно применяются только статические. Динамические - когда хотелось бы обработать ошибки загрузки библиотеки (файл не найден или не той версии) или из соображений безопасности/скрытности:)

Все правильно?:)


 
Барт   (2011-07-22 07:43) [61]

> Loginov Dmitry ©   (21.07.11 23:26) [41]

Почему именно Left? Там и другие слова есть )

{INNER | {LEFT | RIGHT | FULL} OUTER | CROSS } JOIN


 
И. Павел ©   (2011-07-22 07:59) [62]

> [0] Студент   (21.07.11 19:23)

Учи ABAP. Знаю кучу людей, которые не умеют программировать, но, тем не менее, работают программистами и пишут на ABAP.


 
Кщд   (2011-07-22 08:22) [63]

>Loginov Dmitry ©   (21.07.11 23:26) [41]
>Но учти, если есть выбор, то лучше применять LEFT JOIN
это, простите, высококонцентрированная ахинея
не учите дурному


 
Anatoly Podgoretsky ©   (2011-07-22 08:49) [64]

> alexdn  (21.07.2011 21:48:14)  [14]

C ним, с любимым и непотопляемым.


 
Anatoly Podgoretsky ©   (2011-07-22 08:50) [65]

> Rouse_  (21.07.2011 21:50:15)  [15]

А стойку кобры умеешь делать?


 
Anatoly Podgoretsky ©   (2011-07-22 08:52) [66]

> Kerk  (21.07.2011 22:14:17)  [17]

Опять ты о своем Оракле


 
tesseract ©   (2011-07-22 08:54) [67]


> А стойку кобры умеешь делать?


Очковой :-)

>Но учти, если есть выбор, то лучше применять LEFT JOIN

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


 
boriskb ©   (2011-07-22 08:56) [68]


> Знаю Дельфи,


Я начал зарабатывать программированием в 1980 году
Через 6 месяцев решил, что знаю PL/I настолько, что могу в принципе запрограммировать любую задачу.
Потребовалось лет 5 и "знание" еще пяти-8 языков чтобы понять, что я знаю маловато вообще-то.
Лет 10 и изучение 3-х абсолютно разных ОС, что я полуграмотный в этом отношении.
Лет 25  что я  дубоват.

Чтобы мне еще поизучать?


 
Anatoly Podgoretsky ©   (2011-07-22 08:57) [69]

> Rouse_  (21.07.2011 22:21:19)  [19]

Не вполне.

1. правильно по результату, но не по процессу, при inner идет отбор по
условию сразу при выборке, при OUTER сначала выборка, потом отбор, поэтому
производительность второго низкая. Даже при условии отбора строго одинаковых
наборов данных.

2. все записи из первой по условию, а из второй все записи из второй по
условию, плюс NULL записи до комплекта

3. кроме Inner и LEFT еще есть и Right, Full и Cross - естественно не все
субд имеют полный набор соединений


 
Anatoly Podgoretsky ©   (2011-07-22 09:10) [70]

> Фокс Йожин  (21.07.2011 22:21:20)  [20]

Для себя бережем


 
Сергей М. ©   (2011-07-22 09:26) [71]


> Студент   (21.07.11 23:25) [40]


> как я должен был написать?


Лучше бы ты вообще промолчал на эту тему)


 
Дмитрий С ©   (2011-07-22 09:27) [72]


> Anatoly Podgoretsky ©   (22.07.11 08:57) [69]

Ктото знает все тонкости всех join-ов, а кто-то зарабатывает деньги:)


 
Anatoly Podgoretsky ©   (2011-07-22 09:37) [73]

> И. Павел  (22.07.2011 07:59:02)  [62]

Язык для ламеров?


 
oxffff ©   (2011-07-22 09:41) [74]


> Kerk ©   (22.07.11 00:06) [50]
>
> > 65535   (21.07.11 23:39) [45]
> >
> > Использовал в качестве усовершенствования GOF visitor
>
> Целый один раз? Круто. Сразу видно, что очень полезный типовой
> вопрос для собеседования.
>
> Расскажи, кстати, почему именно динамический метод в той
> ситуации использовал. Интересно.


А ты не задумывался, что в любом VСL приложении ты их используешь.

Что касаемо посетителя
google я об этом писал на delphimaster
GOF посетитель oxffff  несколько лет назад.

http://www.delphimaster.net/view/15-1165953376/40-80

P.S. Собственно вопрос очень простой и  выявляет кругозор человека. То есть насколько глубоко человек хочет копать и знать.


 
oxffff ©   (2011-07-22 09:49) [75]


> boriskb ©   (22.07.11 08:56) [68]
>
> > Знаю Дельфи,
>
>
> Я начал зарабатывать программированием в 1980 году
> Через 6 месяцев решил, что знаю PL/I настолько, что могу
> в принципе запрограммировать любую задачу.
> Потребовалось лет 5 и "знание" еще пяти-8 языков чтобы понять,
>  что я знаю маловато вообще-то.
> Лет 10 и изучение 3-х абсолютно разных ОС, что я полуграмотный
> в этом отношении.
> Лет 25  что я  дубоват.
>
> Чтобы мне еще поизучать?


Золотые слова.


 
Anatoly Podgoretsky ©   (2011-07-22 09:51) [76]

> tesseract  (22.07.2011 08:54:07)  [67]

Это глупо советовать везде LEFT JOIN


 
Anatoly Podgoretsky ©   (2011-07-22 09:53) [77]

> boriskb  (22.07.2011 08:56:08)  [68]

Надо написать свою ОС, лучше Виндоус и Юникс, со всей инфраструктурой,
гарантирую что до пенсии больше вопросов не возникнет.


 
boriskb ©   (2011-07-22 09:58) [78]


> Anatoly Podgoretsky ©   (22.07.11 09:53) [77]


:)
Многие знания приумножают скорбь (с)


 
Anatoly Podgoretsky ©   (2011-07-22 10:07) [79]

> boriskb  (22.07.2011 09:58:18)  [78]

Екклесиаст, Соломон?


 
картман_   (2011-07-22 10:12) [80]


>  Sergey Masloff   (22.07.11 06:10) [59]


>  На самом деле SQL очень логичный и простой язык

а в русском всего 33 буквы, но толстые, достоевские и булгаковы появляются раз в столетие - с чего бы?



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

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

Наверх





Память: 0.65 MB
Время: 0.011 c
10-1175837272
Лу
2007-04-06 09:27
2011.11.20
DHTMLEdit.DOM.ExecScript - Отказано в доступе. ( D7 XP )


9-1189869399
ElectriC
2007-09-15 19:16
2011.11.20
Collusion Detection на ID3DXSprite


1-1274191918
Fantasy
2010-05-18 18:11
2011.11.20
Регулярные выражения


2-1311757172
SQLEXPRESS
2011-07-27 12:59
2011.11.20
Работать с Word, не через буфер обмена


2-1312179170
CRLF
2011-08-01 10:12
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
Английский Французский Немецкий Итальянский Португальский Русский Испанский