ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как бороться с частыми изменениями схемы данных?
25 сообщений из 103, страница 2 из 5
  2  все
Как бороться с частыми изменениями схемы данных?
    #38351349
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Cane Cat FisherМораль: нужно предвидеть, где будут частые изменения в будущем, и максимально программно изолировать этот кусок от остального кода. Как учил товарищ Гради Буч, сложность системы определяется не количеством объектов, а количеством и характером связей между ними. Упрощайте логические связи, не допускайте лишних обращений одних подсистем в потроха к другим. И тогда отдельные подсистемы можно будет переделывать быстро и легко, без ущерба для остальных.Вот именно, +1

Любая логика изолируется в одном месте, это касается как расчётов, так и вообще всего остального. Для примера, мне сразу всё понятно, если в средней или крупной системе работа с классами доступа к СУБД пишется непосредственно в прикладном коде. После этого жалобы "ну для этого всё надо переписывать" воспринимаются с подозрением.
...
Рейтинг: 0 / 0
01.08.2013, 11:59
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351353
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
sp"Если изменения на самом деле маленькие..." - я же по русски написал что эти маленькие изменения в цифрах влекут за собой БОЛЬШИЕ изменения в схеме - или вы невнимательно читаете?А, то есть это вы имели в виду, что итоговые значения поменяются немного, а то, что изменения кода большие - это все понимают?
Ну так я и пишу - если заказчик понимает, что изменения кода большие, то в чём проблема? Больше работы - больше денег.
...
Рейтинг: 0 / 0
01.08.2013, 12:02
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351361
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
spКот Матроскин,

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

Можете привести пример описания тарифного плана?
...
Рейтинг: 0 / 0
01.08.2013, 12:06
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351367
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
spalexeyvg,

никакой модели нет - иначе бы я не писал этот топик - если бы была модель и все изменения происходили в рамках этой модели - вообще бы вопрос не стоял!
В том то и дело что при каждом изменении речь идет об изменении модели.Начнём с того, что модель есть всегда, даже если программист не подозревает о её наличии.

Далее, есть модель бизнеса, которая постоянно меняется, а есть модель данных, то есть модель БД.

Так вот, задача разработчика - сделать модель данных такой, что бы её изменения были минимальны при изменении модели бизнеса.
Я собственно об этом говорил.
Естественно, я не утверждаю, что вы сделали плохую модель данных, может быть на самом деле изменения бизнес-модели таковы, что нужно постоянно очень сильно менять модель данных. Это просто предположение, просто призываю вас обратить на это внимание.

Вы же зачем то создали этот топик, не просто же поплакаться? Вот я вам предложил 2 варианта решения проблемы - совершенствовать модель и совершенствовать отношения с заказчиком.
...
Рейтинг: 0 / 0
01.08.2013, 12:09
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351377
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
sp,

Поделитесь пожалуйста опытом борьбы с таким явлением. Есть ли какие либо способы или шаблоны проектирования такого безобразия!? )

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

Я часто реализую в приложениях некие "гибкие модели" вместо прямой реализации постановки. Они в частности реализуют и постановку, но могут больше.
Иногда прокатывает, и не надо делать очередную переделку. Конечно, это не всегда бывает.

Ну и обратное — иногда приструнить фантазии маркетологов вполне допустимо. Обычно очень хорошо помогает внутренняя тарификация работ по IT. Как только люди видят, сколько будет стоить переделка ПО, они все начинают видеть в другом свете.
...
Рейтинг: 0 / 0
01.08.2013, 12:13
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351385
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
miksoftspmiksoft,

еав - ничего не меняет в данном случае - это лишь методология проектирования и на изменения в схеме БД он требует таких же усилий как и при стандартном подходе проектированияЗависит от того, что именно понимать под схемой БД. Физическая схема в EAV не изменяется при изменении логической.
Впрочем, настаивать не буду, вам к своим условиям виднее.

Это все не сильно лечит. Схему может менять и не надо будет, но приложение-то дописывать все равно надо.

Вообще, технические средства тут особенно не помогут.
...
Рейтинг: 0 / 0
01.08.2013, 12:17
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351390
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
spmiksoft,

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

Ещё раз, выставить ему раз счет на работы — сразу присмиреет.
...
Рейтинг: 0 / 0
01.08.2013, 12:20
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351412
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
Cane Cat Fisher,

ваш пример хорош, но не для нашего случая - у нас логика выбора каждого из параметров зависит от значений в других параметрах и она меняется во времени... у вас то всего один пустячек - выбрать цену а у нас все из таких пустячков состоит и при том что у вас структуры за get_price остаются постоянными а они у нас меняются..
...
Рейтинг: 0 / 0
01.08.2013, 12:31
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351417
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
alexeyvgsp"Если изменения на самом деле маленькие..." - я же по русски написал что эти маленькие изменения в цифрах влекут за собой БОЛЬШИЕ изменения в схеме - или вы невнимательно читаете?А, то есть это вы имели в виду, что итоговые значения поменяются немного, а то, что изменения кода большие - это все понимают?
Ну так я и пишу - если заказчик понимает, что изменения кода большие, то в чём проблема? Больше работы - больше денег.

Изменение не кода, а структуры БД!
...
Рейтинг: 0 / 0
01.08.2013, 12:32
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351418
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
MasterZivmiksoftЗависит от того, что именно понимать под схемой БД. Физическая схема в EAV не изменяется при изменении логической.
Впрочем, настаивать не буду, вам к своим условиям виднее.

Это все не сильно лечит. Схему может менять и не надо будет, но приложение-то дописывать все равно надо.

Вообще, технические средства тут особенно не помогут.ИМХО изменение схемы одинаково для EAV или классической схемы.
В конце концов, изменение таблиц и констрейнов такое же изменение таблиц метаданных, как и изменение метаданных в EAV, только в одном случае таблицы метаданных будут системные, в другом пользовательские, ну и язык изменений может отличаться.
Фактически EAV выгоден в том случае, когда бизнес-модель не меняется, когда изменения сводятся к некоему количественному изменению.
...
Рейтинг: 0 / 0
01.08.2013, 12:32
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351420
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
MasterZiv,

к сожалению приструнить товарища из другой конторы мы не можем - они нам хлеб дают!))
...
Рейтинг: 0 / 0
01.08.2013, 12:34
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351421
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
spalexeyvgА, то есть это вы имели в виду, что итоговые значения поменяются немного, а то, что изменения кода большие - это все понимают?
Ну так я и пишу - если заказчик понимает, что изменения кода большие, то в чём проблема? Больше работы - больше денег.

Изменение не кода, а структуры БД!"Код" подразумевается весь набор исходников, в том числе описания таблиц и т.п.
...
Рейтинг: 0 / 0
01.08.2013, 12:34
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351426
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
spMasterZiv,

к сожалению приструнить товарища из другой конторы мы не можем - они нам хлеб дают!))Что значит приситрунить не можем??? Если они дают хлеба меньше, чем нужно для реализации их хотелок, то они совсем не благодетели. Вот тут важно искусство работы с заказчиком - нужно ему доказать, что для изменений, которые он требует, нужно столько-то трудозатрат. Что бы он поверил и у него не было больше вопросов по стоимости.
...
Рейтинг: 0 / 0
01.08.2013, 12:37
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351429
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
alexeyvgspalexeyvg,

никакой модели нет - иначе бы я не писал этот топик - если бы была модель и все изменения происходили в рамках этой модели - вообще бы вопрос не стоял!
В том то и дело что при каждом изменении речь идет об изменении модели.Начнём с того, что модель есть всегда, даже если программист не подозревает о её наличии.

Далее, есть модель бизнеса, которая постоянно меняется, а есть модель данных, то есть модель БД.

Так вот, задача разработчика - сделать модель данных такой, что бы её изменения были минимальны при изменении модели бизнеса.
Я собственно об этом говорил.
Естественно, я не утверждаю, что вы сделали плохую модель данных, может быть на самом деле изменения бизнес-модели таковы, что нужно постоянно очень сильно менять модель данных. Это просто предположение, просто призываю вас обратить на это внимание.

Вы же зачем то создали этот топик, не просто же поплакаться? Вот я вам предложил 2 варианта решения проблемы - совершенствовать модель и совершенствовать отношения с заказчиком.


Эх молодость.. наивность...
Мы уже столько лет в этом бизнесе, что про модель и все ньюансы сами кого хочешь полечить можем)))
Проблема в том что - данный тарифный план это абсолютная вольность методолога - у него нет никаких ограничений и рамок!
Ему нужно варьировать цену при различных условиях - вот он и варьирует их условиями и параметрами так как ему вздумается без всякой схемы!
...
Рейтинг: 0 / 0
01.08.2013, 12:38
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351458
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
Кот Матроскин,

План привести не могу по некоторым причинам но обрисовать его в общем могу так:
в плане есть около 15 постоянных списочных параметров с коэффициентами, не имеющими никакой привязки к предметной области!
а также имеется с 10 параметров условно постоянных.
Методолог эти параметры тусует как ему вздумается - к примеру: если изделие из такого-то цеха и поставляется в такой регион - коэффициент 1 для параметра #1.
Если параметр #1 имеет значение 1 и покупатель не плательщик НДС и из Лондона - то параметр №2 = 0.5

Не шучу! все так и представлено - важно в этом процессе - конечная стоимость, а она формируется такими вот правилами и значениями!
В следующей версии Лондона может и не быть вообще и второе правило переписано так: если это цех №1 и материал кожа, а начальник смены сегодня Пупки - параметр #2 = 2!!!
...
Рейтинг: 0 / 0
01.08.2013, 12:46
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351472
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
spКот Матроскин,

План привести не могу по некоторым причинам но обрисовать его в общем могу так:
в плане есть около 15 постоянных списочных параметров с коэффициентами, не имеющими никакой привязки к предметной области!
а также имеется с 10 параметров условно постоянных.
Методолог эти параметры тусует как ему вздумается - к примеру: если изделие из такого-то цеха и поставляется в такой регион - коэффициент 1 для параметра #1.
Если параметр #1 имеет значение 1 и покупатель не плательщик НДС и из Лондона - то параметр №2 = 0.5

Не шучу! все так и представлено - важно в этом процессе - конечная стоимость, а она формируется такими вот правилами и значениями!
В следующей версии Лондона может и не быть вообще и второе правило переписано так: если это цех №1 и материал кожа, а начальник смены сегодня Пупки - параметр #2 = 2!!!
обычные бизнес правила (тем более что базовое множество определено явно из 25 переменных)
...
Рейтинг: 0 / 0
01.08.2013, 12:49
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351559
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
spКот Матроскин,

План привести не могу по некоторым причинам но обрисовать его в общем могу так:
в плане есть около 15 постоянных списочных параметров с коэффициентами, не имеющими никакой привязки к предметной области!
а также имеется с 10 параметров условно постоянных.
Методолог эти параметры тусует как ему вздумается - к примеру: если изделие из такого-то цеха и поставляется в такой регион - коэффициент 1 для параметра #1.
Если параметр #1 имеет значение 1 и покупатель не плательщик НДС и из Лондона - то параметр №2 = 0.5

Не шучу! все так и представлено - важно в этом процессе - конечная стоимость, а она формируется такими вот правилами и значениями!
В следующей версии Лондона может и не быть вообще и второе правило переписано так: если это цех №1 и материал кожа, а начальник смены сегодня Пупки - параметр #2 = 2!!!

Ну замечательно, не вижу тут особых проблем. на каждый из Ваших параметров делаем "кубик".
Итого тарифный план состоит из 3 основных таблиц
1. Параметры-"кубики"
2. Измерения кубов (N:1 c параметрами)
3. Диапазоны измерений (N:1 c измерениями)

Первый кейс описывается (для цеха N6 и региона N18, Лондон считаем городом № 83 )
Параметры
ID параметраназвание параметра 1Параметр1 2 Параметр2
Измерения
ID измеренияID параметра ссылка на обьект измерения тип (и/или) дефолтное значение 1 1 Номер цеха И 0 2 1 Номер региона И 0 3 2 Покупатель - Плательщик НДС И 0 4 2 Город покупателя И 0 5 2 Параметр1 И 0
диапазоны
ID диапазона ID измерения Начало диапазона Конец диапазона значение 1 1 66 1 2 2 18 18 1 3 3 11 0.5 4 4 83 83 0.5 55 110.5


Если тип измерения И - проверяем что все отобранные диапазоны дают одно и то же значение, если ИЛИ - просто берем значение из первого отобранного диапазона.
...
Рейтинг: 0 / 0
01.08.2013, 13:30
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351612
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
[quot sp]alexeyvgЭх молодость.. наивность...
Мы уже столько лет в этом бизнесе, что про модель и все ньюансы сами кого хочешь полечить можем)))
Проблема в том что - данный тарифный план это абсолютная вольность методолога - у него нет никаких ограничений и рамок!
Ему нужно варьировать цену при различных условиях - вот он и варьирует их условиями и параметрами так как ему вздумается без всякой схемы!

Так не надо эту схему (расчет тарифных планов) хранить в БД :-)
Храните "метаданные" для расчета тарифных планов.
Алгоритм расчета либо выносите в ЯП, либо создайте "конструктор" тарифных планов.
...
Рейтинг: 0 / 0
01.08.2013, 13:56
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351659
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
alexeyvgИМХО изменение схемы одинаково для EAV или классической схемы.

Как раз наоборот.
в EAV добавление нового атрибута -- штатное действие, выполняемое пользователем системы.
Без него -- это установка новой версии ПО, выполняемая программистом.
...
Рейтинг: 0 / 0
01.08.2013, 14:26
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351783
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
spесли изделие из такого-то цеха и поставляется в такой регион - коэффициент 1 для параметра #1.
Если параметр #1 имеет значение 1 и покупатель не плательщик НДС и из Лондона - то параметр №2 = 0.5

Не шучу! все так и представлено - важно в этом процессе - конечная стоимость, а она формируется такими вот правилами и значениями!
В следующей версии Лондона может и не быть вообще и второе правило переписано так: если это цех №1 и материал кожа, а начальник смены сегодня Пупки - параметр #2 = 2!!!

Ничего особенного в этом я не вижу. Только я бы не стал моделировать все это структурами БД, а реализовал в каком-то месте прикладного кода. Со всей историей правил, диапазонами действия во времени и т.д. Особый вопрос - проверка полноты правил, то есть охвата всех возможных комбинаций параметров. "Если это цех №1 и материал кожа, а начальник смены сегодня Пупки - параметр #2 = 2". А если не Пупкин, или Пупкин но не кожа в Цехе № 2, то что?
...
Рейтинг: 0 / 0
01.08.2013, 15:44
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351833
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
Кот Матроскин,

и того надо завести кубик 25 в степени 25!? т.е. предусмотреть все варианты скрещиваний!??
...
Рейтинг: 0 / 0
01.08.2013, 16:10
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351840
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
Cane Cat Fisher
Ничего особенного в этом я не вижу. Только я бы не стал моделировать все это структурами БД, а реализовал в каком-то месте прикладного кода. Со всей историей правил, диапазонами действия во времени и т.д. Особый вопрос - проверка полноты правил, то есть охвата всех возможных комбинаций параметров. "Если это цех №1 и материал кожа, а начальник смены сегодня Пупки - параметр #2 = 2". А если не Пупкин, или Пупкин но не кожа в Цехе № 2, то что?

бывает альтернативный перечень, а бывает просто - ничто!
...
Рейтинг: 0 / 0
01.08.2013, 16:12
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38351943
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
spКот Матроскин,

и того надо завести кубик 25 в степени 25!? т.е. предусмотреть все варианты скрещиваний!??

Зачем "кубик 25 в степени 25"? По примеру же видно, что заводятся только реальные зависимости-измерения, а не потенциальные.
...
Рейтинг: 0 / 0
01.08.2013, 17:16
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38352006
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
spПлан привести не могу по некоторым причинам но обрисовать его в общем могу так:
в плане есть около 15 постоянных списочных параметров с коэффициентами, не имеющими никакой привязки к предметной области!
а также имеется с 10 параметров условно постоянных.
Методолог эти параметры тусует как ему вздумается - к примеру: если изделие из такого-то цеха и поставляется в такой регион - коэффициент 1 для параметра #1.
Если параметр #1 имеет значение 1 и покупатель не плательщик НДС и из Лондона - то параметр №2 = 0.5

Не шучу! все так и представлено - важно в этом процессе - конечная стоимость, а она формируется такими вот правилами и значениями!
В следующей версии Лондона может и не быть вообще и второе правило переписано так: если это цех №1 и материал кожа, а начальник смены сегодня Пупки - параметр #2 = 2!!!Так, отлично. То есть модель постоянна, постоянное количество таблиц и аттрибутов, меняется только код в процедуре расчёта, и всё?
spЭх молодость.. наивность...Спасибо за комплимент :-)
...
Рейтинг: 0 / 0
01.08.2013, 17:55
| Ответить | Цитировать | Написать  
Как бороться с частыми изменениями схемы данных?
    #38352070
Гхостик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гхостик
Гость
2 sp:

Прочитай внимательно старый топик .

spда, и при этом необходимо чтобы, документы, выписываемые задним числом, правильно обрабатывались новой схемой и считали по старым данным!
Как раз по его мотивам: надо вести версионность алгоритмов. Это значит, в базе должны храниться как старые, так и новые версии алгоритмов расчета (хранимых процедур с разными именами), должна быть структура, в которой хранится, на какой период времени какой алгоритм действует, и должна быть сводная ХП, которая по дате расчета берет нужные версии расчетных ХП разных алгоритмов и считает по ним в сумме.
...
Рейтинг: 0 / 0
01.08.2013, 18:57
| Ответить | Цитировать | Написать  
25 сообщений из 103, страница 2 из 5
  2  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как бороться с частыми изменениями схемы данных?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=38351458&tid=1541103]:
 0ms
get settings:
 8ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 153ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 63ms
get tp. blocked users:
 1ms
others: 13ms
total:  271ms
созд. / загр.: 271ms
x
x
Закрыть


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