увеличение времени исполнения запросов к БД

← →
ply © (2008-07-13 02:50) [0]

есть список сотрудников
вот OnShow формы для редактирования данных сотрудника:
if employee_id="0" then //новый сотрудник
begin
query.AddWhere("0");
query.Active:=true;
query.Append;
end
else //вставляем данные о сотруднике
begin
query.AddWhere("employee_id="+employee_id);
query.Active:=true;
if query.eof then exit;

query.edit;
end;

изменяю данные и сохраняю...
query.Post

Проблемы начались когда добавил поле с фотографией сотрудника.
После сохранения\\изменения сотрудника с добавлением фотографии скорость работы программы увеличивается: После каждой добавленной фотографии форма для редактирования сотрудников открывается в среднем на 250мс дольше.
Если фотографий не добвлять то время открытия формы не изменяется.

Как это исправить?

← →
ply © (2008-07-13 02:52) [1]

опечатался. скорость работы не увеличивается а уменьшается.

← →
ply © (2008-07-13 03:04) [2]

блин. опять опечатался=) уменьшается скорость

← →
Германн © (2008-07-13 03:19) [3]

>
> Проблемы начались когда добавил поле с фотографией сотрудника.
>
> После сохранения\\изменения сотрудника с добавлением фотографии
> скорость работы программы увеличивается: После каждой добавленной
> фотографии форма для редактирования сотрудников открывается
> в среднем на 250мс дольше.
> Если фотографий не добвлять то время открытия формы не изменяется.
>
>
> Как это исправить?
>

Удалить поле с фотографией. :)

← →
ply © (2008-07-13 03:20) [4]

не пойдет. без него никак

← →
ply © (2008-07-13 15:20) [5]

решил проблему. у меня был включен sqlmonitor про который я забыл и который писал все запросы в memo

← →
Нат (2008-07-25 05:39) [6]

По любому, хранить изображение в БД - дурной тон.
Храните в БД пути к фото.

← →
Johnmen © (2008-07-25 08:50) [7]

> По любому, хранить изображение в БД - дурной тон.

Что за религия?

← →
Palladin © (2008-07-25 08:51) [8]

Это секта :) "Меганенавистники BLOB полей"

← →
Сергей М. © (2008-07-25 09:40) [9]

> ply © (13.07.08 02:50)

Обработчик OnShow - крайне неподходящее место для такого рода затей.

← →
Ega23 © (2008-07-25 09:44) [10]

> По любому, хранить изображение в БД - дурной тон.

Бугага. :))))))

> Это секта :) "Меганенавистники BLOB полей"

Да это, поди, мускульщик, всю жизнь на древнем MySQL под веб писавший. Там да, не сильно хорошо картинки в БД хранить.

← →
stas © (2008-07-25 09:54) [11]

Нат (25.07.08 05:39) [6]
не прикалуйся.

ply © (13.07.08 02:50)
Фотку не включай в этот запрос, а выводи ее через MasterDetail

← →
Ega23 © (2008-07-25 09:56) [12]

> Фотку не включай в этот запрос, а выводи ее через MasterDetail

Ага, сделай вместо одного - 2 запроса.
Думай что советуешь-то.

← →
stas © (2008-07-25 10:00) [13]

Ega23 © (25.07.08 09:56) [12]
ну, если его запрос возвращает всегда 1 запись тогда ненужно masterdetail.

← →
Ega23 © (2008-07-25 10:00) [14]

> ну, если его запрос возвращает всегда 1 запись тогда ненужно
> masterdetail.

Естественно. Ты на код в [0] смотрел?

← →
stas © (2008-07-25 10:09) [15]

Да, только не ясно что такое query.AddWhere("0");
вобще что за метод такой?

← →
Ega23 © (2008-07-25 10:12) [16]

> Да, только не ясно что такое query.AddWhere("0");
> вобще что за метод такой?

Судя по всему у него какой-то хитрый DAC. Ну а с методом - всё ясно, в "where" что-то добавляет.
Полезный метод, кстати.

← →
stas © (2008-07-25 10:18) [17]

Ega23 © (25.07.08 10:12) [16]
Ну, так query.AddWhere("0") это может быть вобще исключение условия отбора.

← →
stas © (2008-07-25 10:22) [18]

Хотя в любом случае согласен masterdetail здесь ненужен.

← →
Anatoly Podgoretsky © (2008-07-25 14:27) [19]

> Нат (25.07.08 05:39) [6]

Теперь передай изображение на клиента, никаких общих папок на сервере нет.

← →
Нат (2008-07-26 02:50) [20]

> Бугага. :))))))

Это сильный аргумент. :-)

Передача записи с картинкой по сети заметно медленнее, чем без картинки.
И размер картинки может быть 10к, а может и 10Мб.
И не каждый раз пользователю они нужны.
У себя сперва держали вместе, потом разделили на два запроса, потом вообще вынесли наружу.
В общем, вопрос актуальный.

> Теперь передай изображение на клиента, никаких общих папок на сервере нет.

В смысле где хранить? Аргумент... если такое условие...
У себя планировал создать подобную папку с доступном для проги-сервера.

Может ли иметь смысл, с точки зрения обработки прочих полей, создание отдельной таблицы под изображения?

← →
Ega23 © (2008-07-26 13:11) [21]

> Может ли иметь смысл, с точки зрения обработки прочих полей,
> создание отдельной таблицы под изображения?

Сильно зависит от СУБД. В серьёзных - создание отдельной таблицы бессмысленно.

> Это сильный аргумент. :-)

Гораздо более сильный аргумент был про "плохой тон". 9 лет занимаюсь разработкой БД и только сейчас узнаю, что всё что я делаю - плохой тон. И не только я один.
Согласись, это натуральная бугага.

> Передача записи с картинкой по сети заметно медленнее, чем
> без картинки.

А нефиг запросы select * from table гонять. Вот это-то и есть самый настоящий "плохой тон".

> В смысле где хранить? Аргумент... если такое условие...

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

← →
Нат (2008-07-28 07:18) [22]

Есть много разных мнений.
А хуже всего - бывают правы все.
Сколько сторон у монеты... а у шара?

← →
Ega23 © (2008-07-28 09:51) [23]

> А хуже всего - бывают правы все.

Могу предложить тебе завести тему "Хранение BLOB в базе - плохой тон" на, например, sql.ru
Узнаешь много нового.

← →
Anatoly Podgoretsky © (2008-07-28 10:28) [24]

> Ega23 (28.07.2008 9:51:23) [23]

> Узнаешь много нового.

При том не только о хранение.

← →
Игорь Шевченко © (2008-07-28 12:16) [25]

> Есть много разных мнений.

Всего два

← →
MsGuns © (2008-07-28 12:35) [26]

Фотки в основной запрос (который отображается в сетке) не включать вообще, а добавить кнопку "Показать фото", по которолй извлекать фото по ид текущей записи.

ЗЫ. Не надо путать технологию хранения данных (блобы в БД) со способами их отображения (тягания всех блобов на клиента без возможности (и необходимости) сразу их все показывать)

← →
stas © (2008-07-28 13:10) [27]

Нат (28.07.08 07:18) [22]
Может быть и есть случаи, когда в БД хранить фотки не целесообразно, но их на столько мало(я невстречал) что плохим тоном можно считать хранение фоток не в БД. И на это есть очень много аргументов.

ply © (13.07.08 02:50)
Вставку лучше сделать запросом на INSERT, к стати что за СУБД ?

← →
Нат (2008-07-28 17:36) [28]

> добавить кнопку "Показать фото"

Так и делаем

← →
Нат (2008-07-28 17:50) [29]

Забавно, первое, что попалось и конечный результат:
http://sql.ru/forum/actualthread.aspx?bid=6&tid=578237

← →
Ega23 © (2008-07-28 17:58) [30]

> Забавно, первое, что попалось и конечный результат:

В [10] как раз этот случай описан. И это, пожалуй, единственный случай, когда имеет смысл картинки хранить вне базы.

← →
Нат (2008-07-28 18:06) [31]

На sql.ru совершенно спокойное отношение к обоим вариантам.

← →
Ega23 © (2008-07-28 18:11) [32]

> На sql.ru совершенно спокойное отношение к обоим вариантам.

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

← →
Медвежонок Пятачок © (2008-07-28 18:16) [33]

Передача записи с картинкой по сети заметно медленнее, чем без картинки.
И размер картинки может быть 10к, а может и 10Мб.
И не каждый раз пользователю они нужны.

Эт точно. Если картинка не в блобе, то она не по сети тянется, а по эфирным волнам.

← →
Нат (2008-07-28 19:27) [34]

> масса людей не убедила

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

← →
stas © (2008-07-28 22:20) [35]

Нат (28.07.08 19:27) [34]
Какая разница где мусор будет? в папке или в базе?

← →
Нат (2008-07-28 22:45) [36]

Разница для меня: скорость работы, размеры БД, скорость и размеры бэкапов.
Проще работа с картинкам, стандартный софт, грузит сервер БД.
Чуть меньше усилий по уборке мусора в БД.

← →
Нат (2008-07-29 00:05) [37]

оп.. читать ".. не грузит сервер.."
А вообще, конечно, мусор - еща та тема...

← →
Нат (2008-07-29 00:08) [38]

Прошу прощения, за опечатки.
Полезная привычка делать сейвы, в данном случае подводит.
:-(

> скорость работы

Не изменяется. Ну разве только у парадокса... :)

> размеры БД

Какая разница? БД с картинками, или и БД и картинки?

> скорость и размеры бэкапов.

А картинки в бэкап класть не надо????

На самом деле налицо непонимание того, каким образом хранится в таблице BLOB.

Разница в БД-шном хранении картинок и ВНЕ-БД-шном одна, ИМХО, - кто отвечает за целостность данных - СУБД или файловая система. Обычно права проще нарулить в СУБД, ИМХО опять же. Плюс там все равно права надо наруливать на другие поля/записи/таблицы. А рулить в двух местах всяко сложнее.

На мой взгляд оправдано хранить файлы вне БД когда доступ к ним только на чтение и они имеют огромные размеры, требующие соответствующих накопителей. Типа фильмотеки. В других случаях более оправдано хранение в БД.

> На мой взгляд оправдано хранить файлы вне БД когда доступ
> к ним только на чтение и они имеют огромные размеры, требующие
> соответствующих накопителей.

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

> Разница в БД-шном хранении картинок и ВНЕ-БД-шном одна,
> ИМХО, - кто отвечает за целостность данных - СУБД или файловая
> система. Обычно права проще нарулить в СУБД, ИМХО опять
> же. Плюс там все равно права надо наруливать на другие поля/записи/таблицы.
> А рулить в двух местах всяко сложнее.

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

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

> [42] Anatoly Podgoretsky © (29.07.08 10:10)
> Файловая система не отвечает, ей до лампочки

Я неправильно выразился. Имел в виду ОС, которой принадлежит файловая система.

← →
Нат (2008-07-29 10:27) [44]

А нам картинки бэкапить не надо :-)

> если данные не хранятся в базе, то ни о какой целостности говорить нельзя.

Справедливо.

> Нат (29.07.08 10:27) [44]
>
> А нам картинки бэкапить не надо :-)

Вот мы и пришли к тому, что для решения твоей конкретной задачи под конкретную сеть с небольшой пропускной способностью и т.п. технология хранения картинок вне базы - оправдана.
Что отнюдь не охватывает даже 5% задач с БЛОБ-ами и не даёт тебе никакого права вот так безапелляционно заявлять: "По любому, хранить изображение в БД - дурной тон."

> [44] Нат (29.07.08 10:27)
> А нам картинки бэкапить не надо :-)

А они вам вообще нужны? Может просто смешную гиф-ку вместо них показывать? Экономия трафика налицо. 8-)

← →
Нат (2008-07-29 10:47) [47]

Не в праве дело, а в соответствии, не так ли?
Вы свои 5% по анкетам и отклонениям, тоже не считали.

Сговоримся так: это имхо, след-но имею право ошибаться.
И наоборот.

А права ограничивает закон и модератор.

← →
Нат (2008-07-29 10:49) [48]

Sergey13
Так и думаю, для адекватности и полноты данных, они (картинки) явно избыточны.
А клиенту хочется.

> Не в праве дело, а в соответствии, не так ли?

Я видел двух котов. Один был резвый, тёплый и живой, а другой был неподвижный, холодный и мёртвый. Я попытался первого погладить, а он поцарапал мне руку. А вот мёртвого я гладил без проблем. По-любому, оставлять котов живими - дурной тон.

← →
Нат (2008-07-29 11:34) [50]

Это Ваше ИМХО. Тоже очень спорное. Правда?

> Это Ваше ИМХО. Тоже очень спорное. Правда?

Не правда. Это полный бред.
Тем более, что мёртвый кот начнёт вонять через какое-то время.

>Нат
Ну, незнаю про какую СУБД вы говорите. В MSSQL 2005 есть файловые группы, которые можно вынести на отдельный диск не бэкапить, но это часть базы и она будет хранить целостность. Я правда тоже не представляю такой задачи где бэкап части базу нужен, а части ненужен )))

увеличение времени исполнения запросов к БД Найти похожие ветки