Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Об использовании оперативной памяти
|
|||
|---|---|---|---|
|
#18+
softwarer... - очень похоже на госпредприятие, компьютеризированное в ... - начале девяностых .... Вы правы! Т.е. программы мы не выбираем, а надо делать выборки со сложными условиями. Пользователь делает это вручную за определенное количество дней, с определенным количеством ошибок. Хочу привести пример, хоть я и понял, что на форуме лучше не выходить за пределы темы. Открыть новый топик? Не уверен, что это можно решть. 1.Таблица с данными - вертикальная (там показатели всех документов всех типов, одним словом винегрет). На самом деле несколько таблиц, где разделены данные документа, плюс все это по годам. 2.Таблица, где описаны строки каждого документа (несколко сотен на каждый) 3.Таблица со списком документов (несколько десятков). Так вот, выбирать надо из первой горизонтально , сделав примерно 15 граф по условиям из второй и документу из третьей, при этом где-то 7 раз связываю таблицу саму с собой. Делаю запрос. Результат: 2 "автосвязывания" - 2 минуты; 3 - 35 минут 4,... - вылетает в ошибку минут через 15. Таким образом возможности сервера по оптимизации вызывают большие сомнения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2005, 10:12 |
|
||
|
Об использовании оперативной памяти
|
|||
|---|---|---|---|
|
#18+
maa_tmbРезультат: 2 "автосвязывания" - 2 минуты; 3 - 35 минут 4,... - вылетает в ошибку минут через 15.Есть первый результат - и неожиданная его оценка:Таким образом возможности сервера по оптимизации вызывают большие сомненияАнализ ошибки временно отсутствует, но, судя из описания таблиц и их структурыодним словом винегретрациональной индексацией никто не занимался. За счёт каких механизмов ожидается ускорение связывания? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2005, 15:12 |
|
||
|
Об использовании оперативной памяти
|
|||
|---|---|---|---|
|
#18+
Processor...рациональной индексацией никто не занимался. За счёт каких механизмов ожидается ускорение связывания? Почитал вот это synapseтак зачем геморой себе отращивать, раз на sql перешли вот сервак, если толковы будет заботиться о памяти и рациональном использовании ресурсов. и сформулировал запрос с кучей join_ов. Механизм для ускорения связывания? Это предварительное создание временной, более короткой таблицы? Или составление такого запроса, что, например, если в нем (запросе) общий Join с третьей таблицей, то все остальные связывания с собой будут происходить с учетом условия этого Join (а может условие сработает только после того, как все соединит)? Или это что-то еще? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 09:26 |
|
||
|
Об использовании оперативной памяти
|
|||
|---|---|---|---|
|
#18+
maa_tmbПочитал вот это synapseраз на sql перешли вот сервак, если толковы будет заботиться о памяти и рациональном использовании ресурсов. и сформулировал запрос с кучей join_ов. Механизм для ускорения связывания? Это предварительное создание временной, более короткой таблицы? Или это что-то еще?Раньше у вас была база на FOXPRO. Зачем каждая таблица была представлена в двух ипостасях: dbf и cdx? Сейчас у вас:1.Таблица с данными - вертикальная (там показатели всех документов всех типов). 2.Таблица, где описаны строки каждого документа (несколко сотен на каждый) 3.Таблица со списком документов (несколько десятков).По каким полям созданы ключи (кроме первичного)? Есть ли внешние ключи? И какие ключи задействованы в JOIN'ах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 10:55 |
|
||
|
Об использовании оперативной памяти
|
|||
|---|---|---|---|
|
#18+
индексы блин.... Primary key всякие... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 10:55 |
|
||
|
Об использовании оперативной памяти
|
|||
|---|---|---|---|
|
#18+
maa_tmbТаким образом возможности сервера по оптимизации вызывают большие сомнения. Хм. Не так давно Вы описывали методы, которыми добивались скорости на Паскале. Странно, что Вы не сказали вместо этого: ".... возможности Паскаля по оптимизации вызывают большие сомнения....". Что касается описанной задачи - за структуру данных, похоже, надо отрывать руки (как минимум за "по годам"), но ничего действительно страшного не вижу. И, кстати, решительно не вижу, зачем семь раз самосвязывать таблицу. В целом - составьте хорошее описание и идите в форум по выбранной Вами БД; там подскажут, что с этим делать. Хорошее описание - это: - структура таблиц (лучше всего - оператор create table для этих таблиц); индексы, если есть - выполняемый запрос, и если он большой-накрученный - комментарии к нему - план запроса, который возвращает сервер, и прочая информация, которую он даст (количество логических-физических чтений, всякого рода статистика запроса). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 14:21 |
|
||
|
Об использовании оперативной памяти
|
|||
|---|---|---|---|
|
#18+
Ещё несколько аргументов к теме оптимизации. В частности, оперативной памяти... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2005, 14:31 |
|
||
|
Об использовании оперативной памяти
|
|||
|---|---|---|---|
|
#18+
Processor Ещё несколько аргументов к теме оптимизации. В частности, оперативной памяти... К сожалению не имею интернет. SQL.ru - "все что могу" ((с) -"Гоячий снег"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2005, 13:09 |
|
||
|
Об использовании оперативной памяти
|
|||
|---|---|---|---|
|
#18+
maa_tmbК сожалению не имею интернет. SQL.ru - "все что могу" ((с) -"Гоячий снег").Если будет подвоз боеприпасов в Ваш п/я, среди спама найдёте и новую коробочку с орденом в формате .mht весом 104 k. "Если нельзя, но очень хочется, то - можно!" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2005, 14:10 |
|
||
|
Об использовании оперативной памяти
|
|||
|---|---|---|---|
|
#18+
----- The following addresses had permanent fatal errors ----- <adm6820@r68.nalog.ru> (reason: 550 5.7.1 Access denied) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2005, 14:28 |
|
||
|
Об использовании оперативной памяти
|
|||
|---|---|---|---|
|
#18+
Processor----- The following addresses had permanent fatal errors ----- <adm6820@r68.nalog.ru> (reason: 550 5.7.1 Access denied) Ящик не у меня. Serg появится в ближайшие дни, обещал разобраться. А вообще -то письма туда приходят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2005, 17:41 |
|
||
|
Об использовании оперативной памяти
|
|||
|---|---|---|---|
|
#18+
Если в обход не получается, то попробуем взять быка за рога прямо с sql.ru. Если эта ссылка на sql.ru/articles работает (т.е. Вам доступна), пролистайте список статей на 3 экрана вниз. Там увидите заголовок и реферат статьи "Оптимизация – ваш злейший враг". И если Вам её открыть не удастся, то, м.б.,"Serg появится в ближайшие дни" и распечатает её... Желаю успеха! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2005, 18:26 |
|
||
|
Об использовании оперативной памяти
|
|||
|---|---|---|---|
|
#18+
Processor www.sql.ru/articles/articles.aspx "Оптимизация – ваш злейший враг". ... Реферат почитал, мысль выражена верно, можно только добавить, что это как шахаты - просчитываешь вперед на сколько фантазии хватает. А потом узнаешь, что пока гонялся за ладьей, потерял территорию. Жаль, что к моей машине не подключен модем, и сотовый без GPRS, ведь до самой статьи не достучался. Подождем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2005, 08:38 |
|
||
|
|

start [/forum/topic.php?fid=16&startmsg=33083288&tid=1347569]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
71ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 255ms |
| total: | 401ms |

| 0 / 0 |
