ReSQL.ru
     
powered by simpleCommunicator - 2.0.28     © 2024 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Map
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Производительность и количество FK в таблице
25 сообщений из 43, страница 1 из 2
  1  все
Производительность и количество FK в таблице
    #40132904
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Док
Участник
Возможно, надо было спросить в "Проектировании БД", но здесь больше шансов на ответ компетентных людей :)

Есть несколько таблиц-справочников
Код: sql
1.
2.
3.
TBL_PEOPLE (пациенты и работники ЛПУ)
TBL_REASON_VISIT (причина визита в ЛПУ)
TBL_JOB_POSITION (должности работников) ---> является detail для --->TBL_JOB_TITLE (список специальностей персонала)


и др.

и одна общая (аггрегирующая сведения) с данными визитов пациентов в определенные ЛПУ к определенным врачам по определенным причинам и т.д.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
CREATE TABLE TBL_VISITMAIN (
    ID                    INTEGER NOT NULL,
    FK_PEOPLE             INTEGER NOT NULL,
    FK_OFFICE_CLINIC      INTEGER NOT NULL,
    FK_JOB_POSITION       INTEGER NOT NULL,
    FK_REASON_VISIT       INTEGER NOT NULL,
    DATEVISIT             DMN_DATETIME NOT NULL,
    <skiped>
);



Планирую добавить в нее еще пару десятков внешних ключей на подобные таблицы. Чтобы получить минимально полезные сведения приходится городить такую конструкцию
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SELECT
  VM.DATEVISIT,
  JT.NAME ||' '||PM.LAST_NAME AS DOCTOR,
  'пациент '|| PV.LAST_NAME AS PATIENT
FROM TBL_PEOPLE PV
   INNER JOIN TBL_VISITMAIN VM ON (PV.ID = VM.FK_PEOPLE)
   INNER JOIN TBL_REASON_VISIT RV ON (VM.FK_REASON_VISIT = RV.ID)
   INNER JOIN TBL_JOB_POSITION JP ON (VM.FK_JOB_POSITION = JP.ID)
   INNER JOIN TBL_PEOPLE PM ON (JP.FK_PEOPLE = PM.ID)
   INNER JOIN TBL_JOB_TITLE JT ON (JP.FK_JOB_TITLE = JT.ID)
WHERE (PV.ID = :prmID)



Причем, справочники могут быть с блобами.

1. Насколько оправдан такой подход?
2. Есть ли какие-нибудь подводные камни, про которые надо знать?
3. Если мой подход неоптимален, то какую конструкцию можно использовать взамен?
=================
Док.
Win10 Ultim x64/Deb 10 amd64/Darwin Cocoa(Monterey):
FB 3.0.7.33374, Lazarus 2.3.0(trunk); FPC 3.3.1(trunk)
...
Рейтинг: 0 / 0
09.02.2022, 18:57
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40132960
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DmSer
Участник
Док,

выскажу чисто своё мнение.

1. Вовсе не обязательно поля-ссылки на другие таблицы оформлять как FK. Для начала можно оформить как простое поле, например REASON_VISIT_ID. Далее, если выяснится, что по нему требуется поиск, то можно добавить индекс. FK - это сущность опциональная. Если назвать поле REASON_VISIT_ID, то глядя на его название сразу понятно, куда оно ссылается и лишних FK-индексов городить не требуется. В MySQL лет десять не было никаких FK и все прекрасно жили.

2. Вместо того, чтобы городить ненужные FK-индексы в таблице транзакций, гораздо больше пользы реализовать составные индексы, например (ПАЦИЕНТ_ID, DATEVISIT), (ВРАЧ_ID, DATEVISIT), чтобы получить максимально высокую скорость формирования отчётов.

2. Запрос к куче таблиц через INNER JOIN - это лохотрон.
Куда надёжнее строить запрос самостоятельно, начиная с таблицы с транзакциями и подключая через LEFT JOIN таблицы-справочники. Это всегда работает максимально быстро (в отличии от INNER JOIN).
...
Рейтинг: 0 / 0
09.02.2022, 22:42
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40132964
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
DmSerнапример (ПАЦИЕНТ_ID, DATEVISIT), (ВРАЧ_ID, DATEVISIT), чтобы получить максимально высокую скорость формирования отчётов.
лабуда. такие индексы помогут только для отчетов по конкретному пациенту и конкретному врачу. Потому что составные индексы нормально используются только при поиске на равенство по первым сегментам.
Как только первый сегмент сравнивается НЕ на равенство, остальные сегменты идут лесом, поиск по ним невозможен, и такой индекс только затормозит работу из-за своей большей толщины, чем одиночный индекс по конкретному столбцу.
DmSerначиная с таблицы с транзакциями и подключая через LEFT JOIN таблицы-справочники. Это всегда работает максимально быстро (в отличии от INNER JOIN).
опять ерунда какая-то. При inner join оптимизатор сам хорошо выстраивает таблицы и индексы для выборки. При left join он ничего не может, объединяя таблицы по парам в жестко заданном порядке.
Кроме того, использовать left join там где нужен inner - это маразм.
Раньше таким страдали всякие ERP для "прибивания плана", независимо от содержимого таблиц. Но те, кто это писал, не думали, что в универсальной ERP распределение данных в таблицах может быть сильно разным. И если в одной конторе план получается нормальным, то в другой конторе для других данных на том же запросе с left join получается задница и тормоза.
...
Рейтинг: 0 / 0
09.02.2022, 23:02
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40132968
DmSer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DmSer
Участник
kdvлабуда. такие индексы помогут только для отчетов по конкретному пациенту и конкретному врачу. Потому что составные индексы нормально используются только при поиске на равенство по первым сегментам.
Как только первый сегмент сравнивается НЕ на равенство, остальные сегменты идут лесом, поиск по ним невозможен, и такой индекс только затормозит работу из-за своей большей толщины, чем одиночный индекс по конкретному столбцу.

Вероятно, что это и требуется - найти по конкретному врачу (или группе врачей) либо по конкретному пациенту (или группе пациентов).

kdvопять ерунда какая-то. При inner join оптимизатор сам хорошо выстраивает таблицы и индексы для выборки. При left join он ничего не может, объединяя таблицы по парам в жестко заданном порядке.
Кроме того, использовать left join там где нужен inner - это маразм.

Намучался я в своё время с этими inner join. Постоянно у пользователей были проблемы с производительностью (в первую очередь из-за неактуальной статистики). В конце концов переделал все запросы на left join. Не помню ни одного случая, где бы left join (вместо inner join) не подошёл.
...
Рейтинг: 0 / 0
09.02.2022, 23:28
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40132996
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fraks
Участник
kdv

DmSerначиная с таблицы с транзакциями и подключая через LEFT JOIN таблицы-справочники. Это всегда работает максимально быстро (в отличии от INNER JOIN).

опять ерунда какая-то. При inner join оптимизатор сам хорошо выстраивает таблицы и индексы для выборки. При left join он ничего не может, объединяя таблицы по парам в жестко заданном порядке.
Кроме того, использовать left join там где нужен inner - это маразм.

Ну, во первых, именно тут именно inner - НЕ НУЖЕН. Тут как раз outer по смыслу подходит.
А во вторых, раз уж у нас такая ситуация когда мы пошли по ссылке, на которой не навешан FK, то и ссылка может привести к тыкву. И при inner у нас тогда и мастер-запись пропадет.
kdv

Раньше таким страдали всякие ERP для "прибивания плана", независимо от содержимого таблиц. Но те, кто это писал, не думали, что в универсальной ERP распределение данных в таблицах может быть сильно разным. И если в одной конторе план получается нормальным, то в другой конторе для других данных на том же запросе с left join получается задница и тормоза.

Несколько раз напоровшись на ситуацию когда сервер при росте базы пытается "сделать мне лучше" и меняет план на совсем херовый я этих inner боюсь как огня. И всегда когда к данным цепляю справочники, делаю это по outer.
Бывают конечно исключения, но они - исключения.
...
Рейтинг: 0 / 0
10.02.2022, 06:27
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40132997
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fraks
Участник
И я всегда объявляю в базе FK, это неоднократно спасало от кривых данных или удаления записей с зависимостями.
Да, это не совсем бесплатно, но в половине случаев индекс нужен, а в остальных случаях - не так оно и мешает.
Зато самодокументированность и корректность данных.
...
Рейтинг: 0 / 0
10.02.2022, 06:29
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40132998
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fraks
Участник
В моей микровселенной:
У справочников всегда есть первичный ключ с именем ID.
Поля-ссылки начинаются с ID_ и далее идет имя таблицы или некоторые другие исторически сложившиеся называния.

Код: plsql
1.
2.
3.
ID
ID_POST
ID_SKLAD
...
Рейтинг: 0 / 0
10.02.2022, 06:32
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133020
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pastor
Участник
Док
Возможно, надо было спросить в "Проектировании БД", но здесь больше шансов на ответ компетентных людей :)

Планирую добавить в нее еще пару десятков внешних ключей на подобные таблицы. Чтобы получить минимально полезные сведения приходится городить такую конструкцию
...
1. Насколько оправдан такой подход?
2. Есть ли какие-нибудь подводные камни, про которые надо знать?
3. Если мой подход неоптимален, то какую конструкцию можно использовать взамен?
=================
Док.
Win10 Ultim x64/Deb 10 amd64/Darwin Cocoa(Monterey):
FB 3.0.7.33374, Lazarus 2.3.0(trunk); FPC 3.3.1(trunk)


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

из камней - иногда приходится добавлять нолики, т.к. план может внезапно измениться
INNER JOIN TBL_PEOPLE PM ON (JP.FK_PEOPLE = PM.ID+0)
...
Рейтинг: 0 / 0
10.02.2022, 09:43
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133029
Фотография Док
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Док
Участник
Спасибо за мнения. Т.е. пока резюме такое:
* Поменять inner на outer
* Добавление FK вместо составных ключей оправдано и оптимальнее всего

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

Планируется этим запросом выборка данных для конкретного пациента, остальное (кто доктор, цель визита и проч) - меняющиеся детали. По ID визита планируется редактирование записи и отправка ее в отчёт
...
Рейтинг: 0 / 0
10.02.2022, 10:05
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133033
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
ДокПоменять inner на outer

я бы не стал этого делать без острой необходимости.
...
Рейтинг: 0 / 0
10.02.2022, 10:16
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133054
bsv9
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bsv9
Участник
Док,Добавление FK вместо составных ключей оправдано и оптимальнее всего
Не всегда. Я бы, например, очень подумал - добавлять или нет FK на маленький справочник, который не планируется расширять. Например, статус заявки: 1-Активная, 2-Отложена, 3-Удалена.
...
Рейтинг: 0 / 0
10.02.2022, 11:07
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133055
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Док
Есть несколько таблиц-справочников
Код: sql
1.
2.
TBL_PEOPLE (пациенты и работники ЛПУ)
TBL_REASON_VISIT (причина визита в ЛПУ)

Хоть бы до T_ префикс сократил бы что ли...

Док
Код: sql
1.
TBL_JOB_POSITION (должности работников) ---> является detail для --->TBL_JOB_TITLE (список специальностей персонала)

Это должна быть "периодическая таблица" без требований уникальности к паре POSITION + NAME.

Док
и одна общая (аггрегирующая сведения) с данными визитов пациентов в определенные ЛПУ к определенным врачам по определенным причинам и т.д.

Надо объяснять для чего она вообще нужна, и если нужна, то может несколько?
Для хранимых агрегатов нет универсальных правил, увы. В топик призывается Дед.

Док
Код: sql
1.
2.
3.
4.
CREATE TABLE TBL_VISITMAIN (
    ID                    INTEGER NOT NULL,
    PEOPLE             INTEGER NOT NULL,
    FK_OFFICE_CLINIC      INTEGER NOT NULL,



2. Планирую добавить в нее еще пару десятков внешних ключей на подобные таблицы.
3. Чтобы получить минимально полезные сведения приходится городить такую конструкцию
4. Причем, справочники могут быть с блобами.

1. ID_ лучше, чем FK_. Хотя это дело вкуса, конечно (если проект на одного - то пофиг).
2. Таблица c десятками внешних ключей должна автоматически вызывать подозрение.
Есть исключения - например, таблица, которая напарсила (или ещё откуда-то извлекла) всякое
безобразие, которое "плоское" и плохо раскладывается в несколько таблиц (разве что в ширину).
3. Нормальная конструкция. Если, конечно, на каждый чих делать не все 30 джойнов, а только нужные.
4. Выкинь все INNER. Это, конечно, дело вкуса, но таки лучше просто JOIN.

Док

1. Насколько оправдан такой подход?
2. Есть ли какие-нибудь подводные камни, про которые надо знать?
3. Если мой подход неоптимален, то какую конструкцию можно использовать взамен?
1. Вопрос неконкретен. См. выше про хранимые агрегаты.
2. Совпадающие поля в таблицах. Хотя ФБ вроде на них ругается с какой-то версии.
Мелочь, а неприятно. Впрочем, если соблюдать гигиену вегда использовать префиксы, то жить можно.
3. См. п.1. :) Для начала я бы не агрегировал всё подряд и добавил только те FK, которые
реально нужны. Авось и не понадобятся 30 ссылок. Во-вторых, сложность и громоздкость
резко увеличатся, если/когда у тебя вместо одной такой таблицы появится две - например,
TBL_AGG и TBL_AGG_DETAILS (потому что даты или несколько записей или просто потому что).
...
Рейтинг: 0 / 0
10.02.2022, 11:09
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133059
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Док
* Добавление FK вместо составных ключей оправдано и оптимальнее всего
Да. Про "маленькие" справочники правильно подсказывают, хотя целостность данных может быть важнее.

Док
Планируется этим запросом выборка данных для конкретного пациента, остальное (кто доктор, цель визита и проч) - меняющиеся детали.
Они у тебя как-то вшиты или формируются "построителем"/пользователем?
...
Рейтинг: 0 / 0
10.02.2022, 11:15
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133061
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
pastor
иногда еще в таблицу-связку пишу денормализованные данные, т.к. справочники могут поменяться
Тут не понял. Можно подробнее?
...
Рейтинг: 0 / 0
10.02.2022, 11:16
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133063
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pastor
Участник
Гаджимурадов Рустам
pastor
иногда еще в таблицу-связку пишу денормализованные данные, т.к. справочники могут поменяться
Тут не понял. Можно подробнее?


Была в прайсе корова рыжая одна. Например, "Каток"
а потом стало "Физкультурно-оздоровительное катание для иных категорий граждан"

В статистике - одно и то же, а в ОФД уже ушло как ушло.

С диагнозами наверняка также. Или хуже. Был кровавый понос, а стало 10 разных категорий по МКБ.
...
Рейтинг: 0 / 0
10.02.2022, 11:24
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133087
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
pastor> В статистике - одно и то же, а в ОФД уже ушло как ушло.

Всё равно не понял. Если справочник периодический,
то проблемы нет. Если не периодический, то непонятно
как твой подход помогает её решить. Ты же не все поля
в таблицу копируешь?

> С диагнозами наверняка также. Или хуже.
> Был кровавый понос, а стало 10 разных категорий по МКБ.

ХЗ, я бы делал новую запись,
опционально - со ссылкой на
старую, хоть 10 в цепочку.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
10.02.2022, 11:53
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133099
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pastor
Участник
Гаджимурадов Рустам
pastor> В статистике - одно и то же, а в ОФД уже ушло как ушло.

Всё равно не понял. Если справочник периодический,
то проблемы нет. Если не периодический, то непонятно
как твой подход помогает её решить. Ты же не все поля
в таблицу копируешь?

> С диагнозами наверняка также. Или хуже.
> Был кровавый понос, а стало 10 разных категорий по МКБ.

ХЗ, я бы делал новую запись,
опционально - со ссылкой на
старую, хоть 10 в цепочку.


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

пробовали делать истории, получение актуальной на момент времени и пр. - гемор.
компромисс между простотой пользования и возможностями разбора.
...
Рейтинг: 0 / 0
10.02.2022, 12:16
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133105
ggreggory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggreggory
Гость
pastor
Был кровавый понос, а стало 10 разных категорий по МКБ.


Хранение строковых данных в основной таблице раздует её слишком, тормозить будет.

Замените редактирование справочника созданием дубликата со скрытием старого. У новых записей основной таблицы будет новый вариант, у старых останется старый.
...
Рейтинг: 0 / 0
10.02.2022, 12:41
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133123
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pastor
Участник
ggreggory
pastor
Был кровавый понос, а стало 10 разных категорий по МКБ.


Хранение строковых данных в основной таблице раздует её слишком, тормозить будет.

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


а мне не жалко.
я даже логи запросов /ответов http храню. шоп було.
...
Рейтинг: 0 / 0
10.02.2022, 13:26
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133130
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
pastor> может быть полное описание расчета проката или парковки например.
pastor> или стринлист параметров на момент оформления. да что угодно.

Ээээ и сколько (по времени и объемам) это всё безобразие хранится?

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

Это да, нужно вьюхи/ХП плодить.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
10.02.2022, 13:38
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133133
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ДокТ.е. пока резюме такое:
* Поменять inner на outer
* Добавление FK вместо составных ключей оправдано и оптимальнее всего

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

У тебя в запросе условие по полю из справочника. Безмозглое применение п.1 может
привести пушного зверька.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
10.02.2022, 13:40
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133149
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pastor
Участник
Гаджимурадов Рустам
pastor> может быть полное описание расчета проката или парковки например.
pastor> или стринлист параметров на момент оформления. да что угодно.

Ээээ и сколько (по времени и объемам) это всё безобразие хранится?

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

Это да, нужно вьюхи/ХП плодить.


5 лет минимум.
обычно - лет 10, до 50 гб, но там и фотки и все такое.

логи http - год,
логи действий пользователей, телеметрия - до ближайшего обновления БД
...
Рейтинг: 0 / 0
10.02.2022, 13:58
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133197
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Гаджимурадов Рустам
Выкинь все INNER. Это, конечно, дело вкуса, но таки лучше просто JOIN.

Чтобы потом новички и склеротики в гугл лазили успокоить совесть/убедиться, что это одно и то же?
Такие сокращения - упыризм чистой воды.
...
Рейтинг: 0 / 0
10.02.2022, 15:07
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133208
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
YuRock
Гаджимурадов Рустам
Выкинь все INNER. Это, конечно, дело вкуса, но таки лучше просто JOIN.
Чтобы потом новички и склеротики в гугл лазили успокоить совесть/убедиться, что это одно и то же?
Такие сокращения - упыризм чистой воды.
так ты поди и OUTER после LEFT пишешь?
...
Рейтинг: 0 / 0
10.02.2022, 15:23
| Ответить | Цитировать | Написать  
Производительность и количество FK в таблице
    #40133217
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Мимопроходящий
так ты поди и OUTER после LEFT пишешь?
всегда пишу кляузу "as" при указании алиаса для поля.
И? Я еще "не" или уже "тово"?

Запасаться попкорном или уже пора закрывать?
...
Рейтинг: 0 / 0
10.02.2022, 15:34
| Ответить | Цитировать | Написать  
25 сообщений из 43, страница 1 из 2
  1  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Производительность и количество FK в таблице
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru, Чат Кролика       Пашэ: Рисунки, Чат       Фотоальбом: Участники, Встречи
Закрыть
Start [/forum/topic.php?fid=40&startmsg=40132904&tid=1559828]:
 0ms
get settings:
 21ms
get forum list:
 23ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 112ms
get topic data:
 16ms
get forum data:
 3ms
get page messages:
 577ms
get tp. blocked users:
 1ms
others: 362ms
total:  1123ms
созд. / загр.: 1123ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]