|
|
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Мимопроходящий Привет, SergSuper! Ты пишешь: SergSuperS> ЧАЛ из Латвии писалошибаешься. -- With best regards, Мимопроходящий. Posted via ActualForum NNTP Server 1.4 Эта подтема более конструктивна. Разберитесь в ней поглубже, господа! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2007, 16:47 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Бред Спасибо, я удовлетворен Вашим объяснением. Я уже сказал, отвечая pavelvp, что видел бегло пока три СУБД в Cache. И во всех есть таблицы и колонки (просто называется это другими словами, так же как есть отношения и атрибуты в реляционной теории). Пусть поправят лучше знающие, если в чем-то ошибусь. Родная Cache Objects имеет в базовом способе хранения ограничение на число колонок в таблице, просто из-за ограничения на длину записи 32К. Говорится, что можно как угодно переопределять способ хранения данных, но как при этом обеспечивется концептуальная целостность (запросы и т.д.) понятия не имею. Больше мне понравились модели данных и их хранение (не "переопределяемое") в q.Word и X.Magic. В частности, как раз в последней нет ограничений на число колонок в таблице. И именно такую схему я и использовал в тесте. Я не хочу ругать Cache или или хвалить Oracle. Своим постом я хотел показать, что простое сравнение объема занимаемого данными - задача бессмысленная в отрыве от решаемой задачи и от конкретной прикладной постановки. Да, способы организации информации в разных СУБД - разные. Но при любом способе хранения можно добиться минимизации объема. И кстати, предлагаемый мною вариант очень часто используется (к сожалению и где надо и где не надо - честно скажу, что чаще, где не надо). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2007, 17:00 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Очень подходящий ник :)Эта подтема более конструктивна. Разберитесь в ней поглубже, господа! ЧАЛ, голубчик, неглупые люди разобрались уже во всём и без нас :) Психологическая энциклопедия ШИЗОФАЗИЯ - (шизо + греч. phasis - речь) [Kraepelin E., 1913]. Своеобразное проявление мыслительно-речевых расстройств при шизофрении. Первоначально выделялась как особая форма шизофрении, при которой резко выраженная разорванность и совершенно непонятная речь контрастируют с внешней упорядоченностью, известной доступностью и относительной интеллектуальной и аффективной сохранностью больных. Характерна повышенная речевая активность, речевой напор. Выражен симптом монолога, характеризующийся речевой неистощимостью и отсутствием потребности в собеседнике. В настоящее время рассматривается как этап течения параноидной шизофрении [Вроно М.Ш., 1959]. По A. Kronfeld [1940], Ш. близка к разорванности, общим для них является важная роль в формировании клинической картины психомоторно-кататонических динамизмов. Описаны случаи, когда Ш. проявлялась только в письменной речи (шизография) [Levi-Valensy J., Migault P., Lacan J., 1931]. Тратить время на всяких фриков - нет уж увольте :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2007, 17:20 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
БредСлишком много неправды у Вас в одном сообщении.Вот и меня в лгунов записали :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2007, 17:31 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Bogdanov Andrey Выбегалло А где тут 1000 колонок типа int ? А где у Cashe 1000 колонок? Там вообще нет ни одной колонки. Выбегалло А, пардон, сразу не просек. Ну да, ну да - это та самая схема хранения, в которой элементарный запрос надо полдня продумывать, а потом сервер полдня джойны хреначит. Знакомая штука. Время продумывания и время выполнения зависит в основном от умственных способностей продумывающего, а не от сервера и т.п. А нарисуйте мне SELECT A,B,C from table1 WHERE id = 1 and datastamp = '2007-07-26' ? У меня заняло 30 секунд запрос напечатать - сколько у вас займет ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2007, 22:54 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Выбегалло Bogdanov Andrey Выбегалло А где тут 1000 колонок типа int ? А где у Cashe 1000 колонок? Там вообще нет ни одной колонки. Выбегалло А, пардон, сразу не просек. Ну да, ну да - это та самая схема хранения, в которой элементарный запрос надо полдня продумывать, а потом сервер полдня джойны хреначит. Знакомая штука. Время продумывания и время выполнения зависит в основном от умственных способностей продумывающего, а не от сервера и т.п. А нарисуйте мне SELECT A,B,C from table1 WHERE id = 1 and datastamp = '2007-07-26' ? У меня заняло 30 секунд запрос напечатать - сколько у вас займет ? И, кстати, вы как собираетесь char-ы с int-ами хранить - кошерно, в отдельных таблицах, или все в varchar-ы преобразовывать будете ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2007, 23:26 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
ВыбегаллоА нарисуйте мне SELECT A,B,C from table1 WHERE id = 1 and datastamp = '2007-07-26' ? У меня заняло 30 секунд запрос напечатать - сколько у вас займет ? Код: plaintext 1. Итого секунд 25. Ну а вообще, никто не мешает сделать view. ВыбегаллоИ, кстати, вы как собираетесь char-ы с int-ами хранить - кошерно, в отдельных таблицах, или все в varchar-ы преобразовывать будете ? В условиях тестовой задачи было четко сказано "значения типа int". А в реальной жизни я буду выбирать способ хранения наиболее адекватный задаче. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 09:34 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Bogdanov Andrey ВыбегаллоА нарисуйте мне SELECT A,B,C from table1 WHERE id = 1 and datastamp = '2007-07-26' ? У меня заняло 30 секунд запрос напечатать - сколько у вас займет ? Код: plaintext 1. Итого секунд 25. Ну а вообще, никто не мешает сделать view. Maybe Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Так, наверно, более подобно селекту из вопроса? ColId = 4 для колонки id. Кстати, Андрей, как я понял в исходном селекте подразумевалось, что id не уникальны, иначе второе условие бессмыслено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 11:12 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Bogdanov Andrey Бред Спасибо, я удовлетворен Вашим объяснением. Я уже сказал, отвечая pavelvp, что видел бегло пока три СУБД в Cache. И во всех есть таблицы и колонки (просто называется это другими словами, так же как есть отношения и атрибуты в реляционной теории). Пусть поправят лучше знающие, если в чем-то ошибусь. Родная Cache Objects имеет в базовом способе хранения ограничение на число колонок в таблице, просто из-за ограничения на длину записи 32К. Говорится, что можно как угодно переопределять способ хранения данных, но как при этом обеспечивется концептуальная целостность (запросы и т.д.) понятия не имею. Больше мне понравились модели данных и их хранение (не "переопределяемое") в q.Word и X.Magic. В частности, как раз в последней нет ограничений на число колонок в таблице. И именно такую схему я и использовал в тесте. Я не хочу ругать Cache или или хвалить Oracle. Своим постом я хотел показать, что простое сравнение объема занимаемого данными - задача бессмысленная в отрыве от решаемой задачи и от конкретной прикладной постановки. Да, способы организации информации в разных СУБД - разные. Но при любом способе хранения можно добиться минимизации объема. И кстати, предлагаемый мною вариант очень часто используется (к сожалению и где надо и где не надо - честно скажу, что чаще, где не надо). А я просто сравниваю, потому что раздел так называется. Я тоже не ругаю и не хвалю, а привожу результат. Еще раз: у этих колонок могут быть свои ограничения целостности, имена (смысл). Именно Ваш способ и делает тест бессмысленным. Результат Oracle: 1.11 Гб. Я его не ругаю, и не хвалю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 12:55 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Andreww Очень подходящий ник :)Эта подтема более конструктивна. Разберитесь в ней поглубже, господа! ЧАЛ, голубчик, неглупые люди разобрались уже во всём и без нас :) Психологическая энциклопедия ШИЗОФАЗИЯ - (шизо + греч. phasis - речь) [Kraepelin E., 1913]. Своеобразное проявление мыслительно-речевых расстройств при шизофрении. Первоначально выделялась как особая форма шизофрении, при которой резко выраженная разорванность и совершенно непонятная речь контрастируют с внешней упорядоченностью, известной доступностью и относительной интеллектуальной и аффективной сохранностью больных. Характерна повышенная речевая активность, речевой напор. Выражен симптом монолога, характеризующийся речевой неистощимостью и отсутствием потребности в собеседнике. В настоящее время рассматривается как этап течения параноидной шизофрении [Вроно М.Ш., 1959]. По A. Kronfeld [1940], Ш. близка к разорванности, общим для них является важная роль в формировании клинической картины психомоторно-кататонических динамизмов. Описаны случаи, когда Ш. проявлялась только в письменной речи (шизография) [Levi-Valensy J., Migault P., Lacan J., 1931]. Тратить время на всяких фриков - нет уж увольте :) Люди, может кто может попросить чала как-то прореагировать. А то люди как на иголках: "нет уж увольте", а сами с головой погрузились в тему, несчастные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 12:58 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
БредЛюди, может кто может попросить чала как-то прореагировать. А то люди как на иголках: "нет уж увольте", а сами с головой погрузились в тему, несчастные. Вот Вы и попросите :) Вам ведь, наверное сподручнее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 14:47 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) БредЛюди, может кто может попросить чала как-то прореагировать. А то люди как на иголках: "нет уж увольте", а сами с головой погрузились в тему, несчастные. Вот Вы и попросите :) Вам ведь, наверное сподручнее А у Вас какой-то другой результат получился? Вы, уважаемый Сергей Валентинович, вчера при очной встрече говорили, что опубликуете свой результат. А вместо этого тоже переключились на воспоминания о чале. Кстати, я считаю, что Вам сподручнее, все-таки, в соседних зданиях сидите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 15:08 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Вы меня с кем то определенно путаете, Уважаемый Коллега Валентинович - это мой сын (и не Сергей, а Дмитрий, что характерно) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 15:46 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
БредА я просто сравниваю, потому что раздел так называется. Я тоже не ругаю и не хвалю, а привожу результат. Еще раз: у этих колонок могут быть свои ограничения целостности, имена (смысл). Именно Ваш способ и делает тест бессмысленным. Результат Oracle: 1.11 Гб. Я его не ругаю, и не хвалю. Мне как раз кажется, что ваше сравнение совершенно бессмысленно. Вы взяли некий объект в Oracle и некий объект в Cache почему-то решили, что это однородные объекты и решили сравнить их размер. С таким же успехом можно сказать, что у Эйфелевой башни 300 метров, а у великой китайской стены - 6 миллионов метров (могу ошибиться с цифрами). Это сравнение ни о чем. Вот если вы возьмете некую приклдадную задачу, то можно сравнивать ее реализации. Вы можете сказать, что взяли вот задачу хранения разреженных массивов (осталось только строго формализовать ее) и сравнили. Но заметим, что при этом вы сравнили не СУБД, а две ВАШИХ реализации этой задачи. Как только я предложил другую реализацию вы начали навешивать дополнительные требования и ограничения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 15:58 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Bogdanov AndreyС таким же успехом можно сказать, что у Эйфелевой башни 300 метров, а у великой китайской стены - 6 миллионов метров Браво. Великолепная аналогия, и по точности, и по образности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 16:50 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Вы меня с кем то определенно путаете, Уважаемый Коллега Валентинович - это мой сын (и не Сергей, а Дмитрий, что характерно) Сережа, дорогой, ну не надо, пожалуйста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 19:35 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Bogdanov Andrey БредА я просто сравниваю, потому что раздел так называется. Я тоже не ругаю и не хвалю, а привожу результат. Еще раз: у этих колонок могут быть свои ограничения целостности, имена (смысл). Именно Ваш способ и делает тест бессмысленным. Результат Oracle: 1.11 Гб. Я его не ругаю, и не хвалю. Мне как раз кажется, что ваше сравнение совершенно бессмысленно. Вы взяли некий объект в Oracle и некий объект в Cache почему-то решили, что это однородные объекты и решили сравнить их размер. С таким же успехом можно сказать, что у Эйфелевой башни 300 метров, а у великой китайской стены - 6 миллионов метров (могу ошибиться с цифрами). Это сравнение ни о чем. Вот если вы возьмете некую приклдадную задачу, то можно сравнивать ее реализации. Вы можете сказать, что взяли вот задачу хранения разреженных массивов (осталось только строго формализовать ее) и сравнили. Но заметим, что при этом вы сравнили не СУБД, а две ВАШИХ реализации этой задачи. Как только я предложил другую реализацию вы начали навешивать дополнительные требования и ограничения. Вам это именно кажется. Я взял два абсолютно однородных объекта с одинаковой логической структурой , и посмотрел на разницу на физическом уровне. Это настолько очевидно, что непонятно что же Вам там кажется до сих пор? Далее, см. про типы, ограничения целостности и т.д. при переходе к конкретным задачам. О Вашей реализации я сказал ДО ТОГО КАК ВЫ ЕЕ ОПУБЛИКОВАЛИ, заметьте. И именно она делает тест бессмысленным. Вы сделали другой тест. Почему? У меня только одно объяснение: Вас почему-то задели 1.11 Гб (ума не приложу почему; как-будто это единственный минус Oracle). Никаких других объяснений не соглашаться с результатом, полученным Вашим коллегой без умышленного искажения логической структуры данных, я не вижу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 19:42 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer Bogdanov AndreyС таким же успехом можно сказать, что у Эйфелевой башни 300 метров, а у великой китайской стены - 6 миллионов метров Браво. Великолепная аналогия, и по точности, и по образности. Пальцем в небо, как всегда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 19:43 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Бред Вы не в первый раз выдаете фразу, достойную стать Вашей автоподписью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 19:44 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer Bogdanov AndreyС таким же успехом можно сказать, что у Эйфелевой башни 300 метров, а у великой китайской стены - 6 миллионов метров Браво. Великолепная аналогия, и по точности, и по образности. Пальцем в небо, как всегда. И я это четко объяснил. По существу обсуждаемого вопроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 19:50 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
БредИ я это четко объяснил. По существу обсуждаемого вопроса. По существу. Мне часто жаль, что большинство людей не владеет формальной логикой на уровне, достаточном, чтобы мало-мальски трезво оценивать собственные утверждения. В частности, довольно часто человек делает логичное как ему кажется утверждение только потому, что считает свои неполные знания исчерпывающими, и соответственно переводит "я не вижу других вариантов" в "нет других вариантов". То, что заданный Вами вопрос бессмысленен, я объяснил очень давно. С тех пор забавно, конечно, наблюдать, но не более того. Конкретно сейчас Вы делаете одну детскую ошибку: полагаете, что существует однозначное соответствие между логической и физической структурами. Вы исходите из предположения, что "есть логическая структура, которая здесь отражается вот так, здесь отражается эдак". Реально и "здесь" и "там" одна и та же логическая структура отражается уймой способов, найти оптимальное отражение - одна из задач архитектора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 20:15 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
softwarer БредИ я это четко объяснил. По существу обсуждаемого вопроса. По существу. Мне часто жаль, что большинство людей не владеет формальной логикой на уровне, достаточном, чтобы мало-мальски трезво оценивать собственные утверждения. В частности, довольно часто человек делает логичное как ему кажется утверждение только потому, что считает свои неполные знания исчерпывающими, и соответственно переводит "я не вижу других вариантов" в "нет других вариантов". То, что заданный Вами вопрос бессмысленен, я объяснил очень давно. С тех пор забавно, конечно, наблюдать, но не более того. Конкретно сейчас Вы делаете одну детскую ошибку: полагаете, что существует однозначное соответствие между логической и физической структурами. Вы исходите из предположения, что "есть логическая структура, которая здесь отражается вот так, здесь отражается эдак". Реально и "здесь" и "там" одна и та же логическая структура отражается уймой способов, найти оптимальное отражение - одна из задач архитектора. Это Вы, как раз, делаете ошибку, которая не дотягивает даже до детской, оставаясь младенческой: не замечаете подмену логической структуры другой логической структурой. Ну ничего, здесь таких младенцев много. Только как-то грустно, что даже не стремитесь к пониманию предмета Вашего труда. Нелегкого младенческого труда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 20:43 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Привет, Бред! Ты пишешь: БредБ> Это Вы, как раз, делаете ошибку, которая не дотягивает даже до детской, Б> оставаясь младенческой: не замечаете подмену Б> логической структуры другой логической структурой. Б> Ну ничего, здесь таких младенцев много. Б> Только как-то грустно, что даже не стремитесь к Б> пониманию предмета Вашего труда. Б> Нелегкого младенческого труда.о труде однофамильца(?): http://www.sign-forum.ru/./viewtopic.php?t=5364 зы: навеяно музыкой, алкоголем и гуглем... -- With best regards, Мимопроходящий. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 20:47 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
БредТолько как-то грустно, что даже не стремитесь к пониманию предмета Вашего труда. Здравствуйте, Андрей Леонидович. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 21:32 |
|
||
|
Разработка СУБД
|
|||
|---|---|---|---|
|
#18+
Bogdanov Andrey ВыбегаллоА нарисуйте мне SELECT A,B,C from table1 WHERE id = 1 and datastamp = '2007-07-26' ? У меня заняло 30 секунд запрос напечатать - сколько у вас займет ? Код: plaintext 1. Итого секунд 25. Ну а вообще, никто не мешает сделать view. ВыбегаллоИ, кстати, вы как собираетесь char-ы с int-ами хранить - кошерно, в отдельных таблицах, или все в varchar-ы преобразовывать будете ? В условиях тестовой задачи было четко сказано "значения типа int". А в реальной жизни я буду выбирать способ хранения наиболее адекватный задаче. Вы, Андрей, извиняюсь, написали за 25 секунд полную фигню. Начнем с того, что вы попутали RecordID (аналог Row ID, внутренняя переменная) с колонкой ID. Что собственно доказывает мой пойнт - для работы с такими структурами надо иметь немало серого вещества в голове и свободного времени на руках. Вот вам тестовый пример, и попробуйте таки написать SELECT, возвращающий ПРАВИЛЬНЫЕ значения. Дано : "Просто" таблица declare LOCAL TEMPORARY TABLE RealTable( a int, b int, c int, ID int) on commit preserve rows; Засовываем в нее 3 записи : insert into RealTable (a,b,c, ID) values (11, 21, 31, 1); insert into RealTable (a,b,c, ID) values (12, 22, 32, 1); insert into RealTable (a,b,c, ID) values (13, 23, 33, 2); Пишем селект: select a, b, c from RealTable where id = 1; Результат : a,b,c 11,21,31 12,22,32 Теперь переводим все это в "удобную плоскую форму" : declare LOCAL TEMPORARY TABLE EmptyTable( recordID int, colId int, colValue int) on commit preserve rows; /* record 1 */ insert into EmptyTable(RecordId,ColId,ColValue) values (1, 1, 11); insert into EmptyTable(RecordId,ColId,ColValue) values (1, 2, 21); insert into EmptyTable(RecordId,ColId,ColValue) values (1, 3, 31); insert into EmptyTable(RecordId,ColId,ColValue) values (1, 4, 1); /* record 2 */ insert into EmptyTable(RecordId,ColId,ColValue) values (2, 1, 12); insert into EmptyTable(RecordId,ColId,ColValue) values (2, 2, 22); insert into EmptyTable(RecordId,ColId,ColValue) values (2, 3, 32); insert into EmptyTable(RecordId,ColId,ColValue) values (2, 4, 1); /* record 3 */ insert into EmptyTable(RecordId,ColId,ColValue) values (3, 1, 12); insert into EmptyTable(RecordId,ColId,ColValue) values (3, 2, 22); insert into EmptyTable(RecordId,ColId,ColValue) values (3, 3, 32); insert into EmptyTable(RecordId,ColId,ColValue) values (3, 4, 2); Ваш SELECT : select ColValue A, ColValue B, ColValue C from EmptyTable where RecordId = 1; Результаты : A,B,C 11,11,11 21,21,21 31,31,31 1,1,1 Ну полная фигня, верно ? Результаты drev (идея получше), но все равно фигня получается : select max(A), max(B), max(C) from ( select ColValue A, ColValue B, ColValue C, RecordId from emptyTable a where exists ( select 1 from EmptyTable b where b.RecordId = a.RecordId and b.ColId = 4 and b.ColValue = 1) ) tmpr group by RecordId max(a.ColValue as A), max(a.ColValue as B), max(a.ColValue as C) 31,31,31 32,32,32 В общем, думайте еще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 22:11 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=34690261&tid=1553279]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
34ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 146ms |

| 0 / 0 |
