Анонс статьи

← →
Anatoly Podgoretsky © (2009-11-24 20:36) [0]

http://delphimaster.net/view/3-1259081869/

← →
AlexDan © (2009-11-24 20:55) [1]

нету статьи.:)

← →
AlexDan © (2009-11-24 20:57) [2]

The page cannot be found)..

← →
Anatoly Podgoretsky © (2009-11-24 20:58) [3]

Cсылка не кликабельная, мешают пробелы, поэтому надо или скопировать или ко мне на сайт в Библиотеку.

← →
PZ (2009-11-24 20:59) [4]

Есть статья

← →
Anatoly Podgoretsky © (2009-11-24 21:02) [5]

Будем спорить есть или нет? :-)

← →
PZ (2009-11-24 21:03) [6]

Не будем. Я посмотрел статью.

← →
cwl © (2009-11-24 21:03) [7]

И все таки она есть %>

← →
AlexDan © (2009-11-24 21:06) [8]

да, ужо есть..).

← →
Кто б сомневался © (2009-11-24 21:19) [9]

А чего в pdf нельзя чтоли в html было?

← →
Anatoly Podgoretsky © (2009-11-24 21:27) [10]

А так проще и качество выше.

← →
Кто б сомневался © (2009-11-24 21:28) [11]

> А так проще и качество выше.

Вам проще,но всем остальны сложнее..
Кстати ,а чего у вас иконка не прозрачная на сайте?

← →
TUser © (2009-11-24 21:28) [12]

Интерпретатор - он программа, а компьютер - он железный. Пущай работает и не отвлекает программиста на свои мелкие трудности. Имхо.

← →
Anatoly Podgoretsky © (2009-11-24 21:36) [13]

> Пущай работает и не отвлекает программиста на свои мелкие
> трудности. Имхо.

Правильно.
Кроме того я .html не использую, у меня сайт ASP.NET

← →
Inovet © (2009-11-24 21:51) [14]

Прочитал. Хотел было выбрать опечатки и прочие шероховатости, да потом подумал, что непринципиально.

← →
AlexDan © (2009-11-24 22:46) [15]

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

← →
brother © (2009-11-25 04:41) [16]

Анатолий, по поводу опечаток на Вашем сайте:
http://www.podgoretsky.com/ddp/MyDDP.aspx
rfc-1036 - NNTP станларт обмена сообщениями USENET
не ё ;)

← →
brother © (2009-11-25 04:48) [17]

зы. да и год в копирайте поправить не мешало бы...

← →
Дмитрий С © (2009-11-25 06:37) [18]

О чем статья то?

← →
newbie (2009-11-25 07:53) [19]

Спасибо, прочитал.

Полезной оказалась информация про обращения к полям. Когда-то использовал FieldbyName, потом в чужом коде увидел FieldValues и, не задумываясь почему (наверно писать меньше), перешел на него (с производительностью не заморачивался никогда, так как первое требование всегда было: "быстрее сделай!! и чтобы работало!!!"). В связи с этим проскользнула вредная мысля "переписать надо все", но здравый смысл подсказал, что "ну-ка прекращай мозгое..ство!".

← →
Anatoly Podgoretsky © (2009-11-25 09:38) [20]

> brother (25.11.2009 04:41:16) [16]

Не понял, а что не устраивает, это же перевод rfc, я конечно понимаю, что это не стандарт, но авторам хочется так думать, или тебе буква Л не нравится?

Standard for Interchange of USENET Messages

← →
Anatoly Podgoretsky © (2009-11-25 09:43) [21]

> newbie (25.11.2009 07:53:19) [19]

Я в статье указал, что есть и другие методы, производные от этих, но целью статьи не является рассмотрение всех методов, а только показать явное обращение по отношению к неявному и к чему это приводит и некоторые подводные камни и соотношение с оптимизацией. FieldValues считаю вредной функцией, как еще и ряд других.

Но статья не о том, как работать с БД

← →
newbie (2009-11-25 09:50) [22]

> Но статья не о том, как работать с БД

Я и не воспринимаю ее так.

← →
chupakabra (2009-11-25 09:53) [23]

Удалено модератором

← →
sniknik © (2009-11-25 10:10) [24]

из статьи
> Доступ к полям
> 1 ... 4 ... методы
пользуюсь практически всегда 5м ("скрещенные" 1м и 3им), т.е. при разовом обращении к полю использую Edit1.Text := CustTable.FieldByName(‘FieldName’).AsString; при множественных обращениях (циклы), что бывает чаще всего, чаще разовых. Делаю сначала
fFieldName:= CustTable.FieldByName(‘FieldName’); //(fFieldName: TField)
и дальше в цикле Edit1.Text := fFieldName.AsString; //(естественно тут просто пример, присваивать в цикле все значения одной переменной глупо)

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

← →
Anatoly Podgoretsky © (2009-11-25 10:16) [25]

> sniknik (25.11.2009 10:10:24) [24]

Видимо надо добавить этот метод в статью, уже несколько человек намекнули на него, все равно надо исправить ряд опечаток

← →
brother © (2009-11-25 10:20) [26]

> или тебе буква Л не нравится?

ну да) вроде как должно быть написано стандарт

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

Или наоборот - применение параметров может значительно снизить быстродействие :)

> brother (25.11.2009 10:20:26) [26]

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

Мне тоже так кажется
яяя

> Игорь Шевченко (25.11.2009 10:40:27) [27]

Игорь, это зависит от того как смотреть в каком контексте фраза. Ведь факт предкомпиляции у большинства СУБД никто не отменял, особенно важно это при массовой обработке в цикле. И может это также зависеть от сервера. Но это не отменяет других плюсов.

> Не стоит подставлять в запрос переменные.

Интересная мысль...

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

Anatoly Podgoretsky © (25.11.09 11:13) [29]

В блаженной памяти СУБД Oracle в одно время тоже решили, что параметры всегда и везде - это хорошо и ввели параметр CURSOR_SHARING, при котором все константы в запросах принудительно заменялись на параметры.
Наткнулись на проблемы с производительностью.

> Игорь Шевченко (25.11.2009 11:45:32) [32]

Ну они всегда себе на уме.

Опубликованая исправленая версия с дополнениями, дополнений не очень много.

← →
ANB (2009-11-26 09:33) [36]

> В блаженной памяти СУБД Oracle в одно время тоже решили,
> что параметры всегда и везде - это хорошо и ввели параметр
> CURSOR_SHARING, при котором все константы в запросах принудительно
> заменялись на параметры.
> Наткнулись на проблемы с производительностью.

Очень спорный вопрос.

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

А для 10% случаев параметры действительно могут вызвать проблемы с производительностью.

Цифры процентов взяты от фонаря.

ИМХО : опцию вырубить, писать стараться с параметрами, в узких случаях - переделывать на константы. Впрочем, хинты тоже помогают.

У нас есть много кусков кода, где анализируются входные параметры и строятся разные хинты а то и запросы для оптимальной скорости выполнения.

Это все подстраивание под конкретный сервер. Тоже имеет право на существование.

Анонс статьи Найти похожие ветки