|
|
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Last1Cmen, 1С - хороший продукт. Если нет желания [сил,способностей] (нужное подчеркнуть) самостоятельно проектировать все три слоя приложения, то конечно хороший продукт. Комментарии здесь излишни. Только нужно принимать во внимание это. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2009, 18:07 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Last1Cmen, Абсолютные разные отделы абсолютно разных компаний :) Может подходы одинаковые? Но это просто совпадение, не более. :) По поводу "жестко" - Вы же не будете отрицать,что Cправочник.XXX жестко равен таблице "SCXXXX", Документ.XXXX жестко равен минимум определенному IDDOCDEF в _1SJOURN, и при наличии соотв. атрибутов жестко определен соответствующими DHXXXX и\или DTXXXX (для 1С 7.7)? У Искры есть более иные жесткие соответствия, в более других системах - другие. Но без определенной жесткости ни одной современной ИС не обойтись. И не важно на какой платформе эта ИС создана... ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2009, 18:08 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Егоров Александр, ну вот этим вся "жесткость" и заканчивается... ещё правда уникальность внутренних ИД (в принципе ни первое ни второе не проблема - только вот смысел этого под вопросом)... да и у любой системы на рсубд в любом случае есть жесткие таблицы, ключи и т.д... ну можно самому давать им имена не рискуя дальнейшим сопровождением и обновлениями но разве автору это надо ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2009, 18:14 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Last1Cmeniтенденция "комментирования" всего что связано с 1це сводящаяся к тому что это не продукт а жестко-немодифицируемая тягомотина не в состоянии ничего решить четко прослеживается ;) Выразился бы немного не так. Искра предоставляет несколько иные подходы к реализации ИС. Являясь по сути таким же конструктором, как и Конфигуратор 1С - предосталяя несколько более расширенные возможности по работе конкретной "конфигурации" с конкретной БД. И продвигает несколько другой подход к "кастомизации" ИС. Вернее продвигает "противоположный 1С" подход, предлагая взамен кастомизации инструмент "более быстрой разработки, но с нуля". В связи с этим и некоторый... эээ... маркетинг. :) Хотя лично мне Искровый подход более симпатичен, но сам я "погряз в 1С", ибо глубинка... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2009, 18:21 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Егоров Александр, да что ж я против чтоль... бога ради... просто уже даже не веселят "мегапроекты" в десяток человеко-часов на той же 1це в килобаксы на какой-нить "крутой" ерп платформе причем мотивировка не в том что мол сотням юзеров нужно обеспечить доступ к миллиардам записей или отсутствии типового модуля производства отличающегося от многопередельного скажем... а просто потому что... и пАшло и пАехало ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2009, 18:26 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Last1CmenЕгоров Александр, ну вот этим вся "жесткость" и заканчивается Это принципиальная жесткость! :) А если мне надо вторую табличную форму в документе? А если мне надо связь спрвочников "многое-ко-многим"? А если мне вместо "проведен\непроведен" необходимо "принят оператором\отправлен на склад\отобран\передан экспедитору\принят бухгалетрией"? Понятно, что если мне это надо, я сделаю это и в 1С, но только или громоздя дополнителные конструкции, или выйдя за рамки платформы. Даже используя "внешние компоненты", функционал встроенных объектов изменить невозможно. Хотя это справедливо не только для "конфигураторов", но и для любых RAD в целом. Другое дело, что RAD тем лучше, чем больше она предоставляет инструментов для собственного расширения. ;) Last1Cmen"ещё правда уникальность внутренних ИД (в принципе ни первое ни второе не проблема - только вот смысел этого под вопросом)... да и у любой системы на рсубд в любом случае есть жесткие таблицы, ключи и т.д... Собсно этого-то 1С как раз и не дает - используется клиентская поддержка целостности и структуры. Возможности поддерживаемых РСУБД как для этого не использовались, так и не используются (поправьте, если это не так для 8.х). Last1Cmenну можно самому давать им имена не рискуя дальнейшим сопровождением и обновлениями но разве автору это надо ? Автор пропал уже на второй странице топика. Остается только спорить между собой, что же автору было надо :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2009, 18:37 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Last1CmenЕгоров Александр, да что ж я против чтоль... бога ради... просто уже даже не веселят "мегапроекты" в десяток человеко-часов на той же 1це в килобаксы на какой-нить "крутой" ерп платформе Вот тут полностью согласен. Каждому инструменту - своя ниша. И в своей нише 1Су так же нет равных, как какой-нить крутой erp - в своей. Обидно только когда какую-то конкретную задачу начинают решать совершенно не тем инструментом. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2009, 18:41 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
авторСобсно этого-то 1С как раз и не дает - используется клиентская поддержка целостности и структуры. а попробуйте проапдейтить напрямую с совпадением примари ключей ;) ?... тут уже серверная часть отругается и откатит транзакцию так что клиенту клиентское а серверу - серверное авторА если мне надо вторую табличную форму в документе? в 7ке это действительно сложно в отличии от следующего продукта авторА если мне надо связь спрвочников "многое-ко-многим"? вот ни разу целесообразности в этом не видел честно авторА если мне вместо "проведен\непроведен" необходимо "принят оператором\отправлен на склад\отобран\передан экспедитору\принят бухгалетрией"? хорошо а если вместо "принят и т.д." нам нужно именно "проведен/непроведен" так чего - та система где в базе этого нет тоже плохая ?... копей тут поломано немало и до нас и будет поломано после нас... все проблемы решать в частности надо... где то выходит на первые рамки производительность где-то скорость разработки и модификации, где-то отказоустойчивость, где-то секьюрность, где-то маштабируемость и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2009, 18:45 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Last1CmenавторСобсно этого-то 1С как раз и не дает - используется клиентская поддержка целостности и структуры. а попробуйте проапдейтить напрямую с совпадением примари ключей ;) ?... тут уже серверная часть отругается и откатит транзакцию так что клиенту клиентское а серверу - серверное А попробуйте напрямую удалить справочник, не удаляя его подчиненные? Получится очень даже лего ;) Потом, конечно, "тестирование и исправление" вылечит. ;) А ведь казалось бы банальный FK с cascade delete... :) Last1CmenавторА если мне надо вторую табличную форму в документе? в 7ке это действительно сложно в отличии от следующего продуктаЗнаю, что в 8.х это есть, но сейчас уже очень сложно перенести получившуюся из типовой "самописку". проще внедрить типовую 8.х, освоить ее иначать переписывать заново. Это, кстати, не в обиду платформе - это больше в обиду "писателям" типовых на этой платформе. Уж насколько типовые корявее самой платформы... Хотя зато "купил и работай"... какое-то время... :) Last1CmenавторА если мне надо связь спрвочников "многое-ко-многим"? вот ни разу целесообразности в этом не видел честноВозможно спорный пункт, не спорю, но платформа не даст такой возможности, если она понадобится. Хотя в 8.x такое можно сделат на регистре сведений. Last1CmenавторА если мне вместо "проведен\непроведен" необходимо "принят оператором\отправлен на склад\отобран\передан экспедитору\принят бухгалетрией"? хорошо а если вместо "принят и т.д." нам нужно именно "проведен/непроведен" так чего - та система где в базе этого нет тоже плохая ?...Дык если "статус документа" является множеством - он может быть в рамках одной системы и "проведен\непроведен", и "принят\отпрален\отобран и т.д.". Last1Cmenкопей тут поломано немало и до нас и будет поломано после нас... все проблемы решать в частности надо... где то выходит на первые рамки производительность где-то скорость разработки и модификации, где-то отказоустойчивость, где-то секьюрность, где-то маштабируемость и т.д."Больше систем - хороших и разных" (с) опять таки полностью согласен. Но боже упаси забивать гвозди отверткой и закручивать шурупы молотком... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2009, 19:12 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Сильно много ожиданий от 1С. Нишевый продукт - документоориентированные учетные задачи (в СНГовии - основа компьютеризации). Дай бог им здоровья, кстати. Столько людей обеспечили работой. Журнал даже свой выпускают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2009, 19:32 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Пам-па-пааааам!!! Вроде сделал набросок. Показываю отрывки из модуля, где хранятся все подсказки графической оболочке, как работать с заданной БД. Это пример описания таблицы: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. А вот пример описания отчета: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. И еще немножко настроек: Код: plaintext 1. 2. 3. Но, как это всегда со мной бывает, пока я делал этим способом мне в голову пришел еще один, по-моему, более приятный сделать то, что я хочу. Привожу черновик кода, похожего на SQL: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Опишу все по порядку. Первое, надо описать все элементы разделы (таблицы и отчеты, они появятся в иерархическом списке слева в главном окне программы): Код: plaintext 1. 2. 3. Мы описали все эти таблицы. Потом описываем все действия над каждой из этих таблиц. Следующий кусок определяет запрос БД, который нужно выполнить, чтобы получить содержимое таблицы. Таблица, которая будет получена в результате этого запроса пользователь увидит в центральной части окна. Код: plaintext 1. А эта часть определяет запрос, который нужно выполнить при нажатии на кнопку "Добавить" пользовательского интерфейса. Обратите внимание на параметр "{{TEXT|Название}}". Если в запросе есть параметры, заключеные в двойные фигурные скобки, то перед тем, как выполнить запрос, пользователю будет показано красивое диалоговое окно, где он должен будет ввести значения всех параметров. В БД есть триггер, который следит за тем, чтобы поле "name" было не пустым. Если юзер забудет ввести что-нибудь в поле "Название", он увидит сообщение об ошибке, которое выдает этот триггер. Код: plaintext 1. И так определяются все-все действия, которые могут понадобиться пользователю (пожалуй, их немного: удаление, редактирование, фильтры). Если какая-либо управляющая запись отсутствует, значит это действие недоступно пользователю. Ну как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2009, 22:24 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
alexdup Ну как? вполне можно переходить на следующий уровень , правда до первой страницы еще далеко, и идей никаких нет, в отличие от автора по ссылке. Но задор... p.s. если серьезно... Не сердитесь сильно, приступ сарказма. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2009, 00:34 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
iscrafmalexdup Ну как? вполне можно переходить на следующий уровень , правда до первой страницы еще далеко, и идей никаких нет, в отличие от автора по ссылке. Но задор... p.s. если серьезно... Не сердитесь сильно, приступ сарказма. Объясните, какой уровень? Можете не извининяться, я прекрасно понимаю, что мои потуги вызывают саркастическое настроение. У меня нет систематических знанаий в этой области, поэтому я могу напридумывать много смешного. Я начал эту тему, чтобы знающие люди посоветовали мне, какими средствами НОРМАЛЬНЫЕ люди, делают то, что я описываю. Не верю, что для каждой малюсенькой системы нужно разрабатывать интерфейс с нуля. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2009, 09:35 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
автордля каждой малюсенькой системы нужно разрабатывать интерфейс с нуля ну если наработок уже куча то понятие "с нуля" обычно уже не такое уж и "с нуля" :) вот есть у вас хотя бы минимальный опыт "проектирования" систем с гуй-ем ну или самого интерфейса к бд ? если есть то может попробовать на том в чем разбираетесь а потом уже по желанию поднатягав себя там где хочется тем или иным образом портировать туда я отнюдь не ратую за 1це (хотя для вашей задачи имхо лучше и не придумаешь) или тот же акцесс (помидорами не кидать) но в любом из случаев разбирательств с любой даже простейшей учетной средой/системой времени будет угроблено много пока прийдет хоть какое-то понимание... а может и вообще не прийдёт :) пс... чет я с утра расфилософствовалсо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2009, 10:46 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Last1Cmenавтордля каждой малюсенькой системы нужно разрабатывать интерфейс с нуля ну если наработок уже куча то понятие "с нуля" обычно уже не такое уж и "с нуля" :) То, что я вам презентую в этом топике - можно считать наработками? Last1Cmen вот есть у вас хотя бы минимальный опыт "проектирования" систем с гуй-ем ну или самого интерфейса к бд ? если есть то может попробовать на том в чем разбираетесь а потом уже по желанию поднатягав себя там где хочется тем или иным образом портировать туда Опыт есть во-первых на эксесе. Во-вторых для задачи учета, которую я решаю, у меня было уже почти готовое решение. Но гуй и бд я программировал вперемешку в связке pyhton/sqlite по принципу "лишь бы работало", не задумываясь об элегантности, если можно так выразиться. Из-за этого, естественно, когда я получил задание на небольшую модификацию учета и аналитики, я понял что я наговнокодил очень неповоротливую систему, модификация которой потребует очень много усилий! Как раз после этого я и начал задумываться об отделении структуры от интерфейса. Чтобы не изобретать велосипедов, я обратился к вам, чтобы узнать какой опыт есть у человечества в этой проблеме. Last1Cmen я отнюдь не ратую за 1це (хотя для вашей задачи имхо лучше и не придумаешь) или тот же акцесс (помидорами не кидать) но в любом из случаев разбирательств с любой даже простейшей учетной средой/системой времени будет угроблено много пока прийдет хоть какое-то понимание... а может и вообще не прийдёт :) За 1C и Access спасибо, но за Access я иррационально ненавижу, а 1С надо покупаать. Мне бы чего-нибудь бесплатненького. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2009, 11:44 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Короче, как всегда. Напишешь программисту требование: "сложи 2+2". Он засядет на 2 года и напишет программу-калькулятор со встроенным языком, исполняемым на на собственной виртуальной машине. Интересно знать, кто оплачивает ваше изобретение велосипедов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2009, 14:32 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
astonКороче, как всегда. Напишешь программисту требование: "сложи 2+2". Он засядет на 2 года и напишет программу-калькулятор со встроенным языком, исполняемым на на собственной виртуальной машине.quot] А завтра напишешь ему 2+3, а потом вообще умножить. А ему что бедному делать? [quot aston]Интересно знать, кто оплачивает ваше изобретение велосипедов? Работаю на пол-ставки, вообще в основном помогаю тетям в работе с компьютером. Вот спросили, смогу ли я сделать такую систему учета. Так как мне это интересно, согласился и теперь делаю. Со сроками не торопят. Я, как вы уже могли догадаться, по происхождению программист, а в проектировании БД у меня систематических знаний нет, поэтому это накладывает свой отпечаток (это я про "сложи 2+2"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2009, 15:13 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
alexdup, Если вы приведете краткое описание и назначение таблиц то сможете получить конкретные рекомендации. По поводу: "Отчеты/Отчет по главному складу", "Остатки книг на главном складе". Абстрагируйтесь немного от текущей задачи и поразмышляйте о перспективах: Представьте, что у вас несколько складов и существует необходимость получать остатки по различным складам (в том числе например по удаленным). В этом случае рекомендуется добавить такую сущность как склад, и хранить остатки в разрезе складов. В этом случае ваш отчет "остатки книг на главном складе", модернизируется в отчет "остатки книг по складам" (или на выбранном складе). Еще раз призываю в первую очередь сначала продумать сущностную и функциональные модели системы, потом структуру таблиц, а потом уже приступить к программированию логики. Такой подход позволит избежать лишних кардинальных переделок. Кратко сущностная модель: Книга - сущность отражает объект учета, характеризуется наименованием, авторами, ISDN код, датой выпуска, изданием и т.п. Авторы книг - сущность отражает одну из характеристик книг, связь Книга - Автор "один" ко "многим". Издательства - сущность отражает издательства выпускающие книги, связь Книга издательство Один к одному Склад - сущность отражает местонахождения Книги (в том числе Главный склад, Удаленный Склад) и т.п. Функциональная модель: Поступление книг на главный склад (или на удаленный если такое имеет место быть) Перемещение книг между складами (расход с одного склада, приход на другой) Списание книг со склада (порча, выбытие и т.п.) Отчет по остаткам книг на складах на дату Отчет по обороту книг в разрезе видов операций между складами и т.п. Различные отчеты по характеристикам книг (количество книг по авторам, издательствам, годам выпуска и т.п.). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2009, 16:12 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
alexdupа 1С надо покупаать. Мне бы чего-нибудь бесплатненького. Access, тоже, кстати, отнюдь не бесплатен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2009, 16:26 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Dinamoalexdup, Если вы приведете краткое описание и назначение таблиц то сможете получить конкретные рекомендации. Приведу задачу целиком. Есть образовательное учреждение, которое имеет несколько филиалов в городах россии. Обучение ведется по нескольким учебным курсам: А, B, C (это не пример, они действительно так называются). По каждому учебному курсу есть по 3 книги. Когда учебные центры осуществляют набор по какой либо программе, они просят прислать им нужное количество книг №1. Ближе к середине они просят прислать какое-либо количество книг №2 и в конце №3. С учетом неизвестности количества записавшихся на курс, количество оплативших, количества выбывших и прочих факторов: 1. Количества разных книг по одной программе не совпадает 2. Количество книг, выданных в регионах меньше, количества книг, им отправленных. Книги отправляются с единственного главного склада. Сомневаюсь, что когда-нибудь их станет 2 или больше. Учет нужен для того, чтобы всегда знать количество книг, которые сейчас находятся в регионах. И когда в следующий раз они будут просить прислать им книг, мы пришлем не заявленное количество, а вычтем из него те книги, которые у них остались с прошлых разов. Вот так, все просто. Логическую в данном случае придумать не представляет большой сложности. А вот с инструментарием я в размышлениях. Думаю на 1С ради такой ерунды мне денег не дадут. Кстати, у нас есть купленный SharePoint Server, но, по организационным причинам, он будет введен в действие еще очень нескоро. Насколько он подходит для решения данной задачи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2009, 16:32 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Все готово. Кому интересно, привожу файл настройки текущей системы учета. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2009, 23:01 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
alexdup, забыли систему учета приложить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2009, 23:24 |
|
||
|
Графическая оболочка БД
|
|||
|---|---|---|---|
|
#18+
Круто у вас тут - даже боязно. Спор просто захватил. Предлагаю посмотреть на ситуацию с точки зрения TCO (Общей стоимости владения). Насколько понимаю суть : у 1С первоначальные затраты при внедрении заманчиво малы и если не отходить от базовой конфигурации - то вполне приемлемые. Однако, если разрабатывать, а затем поддерживать уникальную конфигурацию - стоимость сопровождения может быть очень существенной (стоимость специалиста 1С сейчас высоковата). Мне кажется что небольшой проект лучше выполнить на 1С только в том случае если имеется необходимая типовая конфигурация. Я прав? не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2009, 11:38 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36260481&tid=1542979]: |
0ms |
get settings: |
12ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
164ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 240ms |
| total: | 516ms |

| 0 / 0 |
