подскажите хорошую практику наименования связанных таблиц / Проектирование БД

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / подскажите хорошую практику наименования связанных таблиц

25 сообщений из 132, страница 3 из 6

все

подскажите хорошую практику наименования связанных таблиц

#39997044

Валерий Юринский

Участник

Откуда: Москва, "ФОРС Дистрибуция"

Сообщения: 1 357

Рейтинг: 0 / 0

Dimkas

crutchmaster,
именно потребность в автоматизации построения запросов и породила решение

"знаешь идентификатор таблицы - знаешь о ней почти всё"

Хорошее решение!

Приведите, пожалуйста, пример, чтобы публика оценила.

...

Рейтинг:

0 / 0

09.09.2020, 19:21

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997048

Валерий Юринский

Участник

Откуда: Москва, "ФОРС Дистрибуция"

Сообщения: 1 357

Рейтинг: 0 / 0

Dimkas

А как выглядит запрос списка департаментов и обслуживаемых ими клиентов?
Очевидно

Код: plsql

1.
2.
3.

select d.name department_name, c.name client_name from
department_client d_c, department d, client c where
d_c.client_id = c.id and d_c.department_id = d.id

Я бы оформил это так:

Код: plsql

1.
2.
3.
4.
5.
6.
7.

select d.name AS department_name
     , c.name AS client_name 
from department_client d_c
   , department d
   , client c 
where d_c.client_id = c.id 
  and d_c.department_id = d.id

Считаю, что это лучше читается, а значит поможет избежать ошибок.

Но это уже другая тема.
Извините за оффтоп.

...

Рейтинг:

0 / 0

09.09.2020, 19:29

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997154

zeon11

Участник

Откуда: Сибирь, Кемерово

Сообщения: 1 195

Рейтинг: 0 / 0

Валерий Юринский

Dimkas

......

Я бы оформил это так:

Код: plsql

1.
2.
3.
4.
5.
6.
7.

select d.name AS department_name
     , c.name AS client_name 
from department_client d_c
   , department d
   , client c 
where d_c.client_id = c.id 
  and d_c.department_id = d.id

Считаю, что это лучше читается, а значит поможет избежать ошибок.

Но это уже другая тема.
Извините за оффтоп.

Если уж запятые впереди (а это действительно удобно), тогда и where надо оформлять в том-же стиле:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.

select d.name AS department_name
     , c.name AS client_name 
from department_client d_c
   , department d
   , client c 
where 1=1
  and d_c.client_id = c.id 
  and d_c.department_id = d.id

...

Рейтинг:

0 / 0

10.09.2020, 08:48

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997516

Dimkas

Гость

Валерий Юринский

Приведите, пожалуйста, пример, чтобы публика оценила.

Пример, таблица MO содержит поля:
IDMO - автоинкрементный ключ,
MO - наименование,
IDTMO - ссылка на какую таблицу? ;)

+ там же поля периода действия записи, которые имеют одинаковые названия во всех таблицах:
BGDATE - дата введения в действие
BGREASON - основание введения в действие

MDDATE - дата последнего изменения
MDREASON - основание последнего изменения

CLDATE - дата прекращения действия
CLREASON - основание прекращения действия

CRDATE - дата создания

В итоге по одному идентификатору таблицы знаем как минимум 9 полей + можем пойти в служебные таблицы
за разъяснениями по поводу типа таблицы, ее наименования и полного списка полей.

Также из идентификатора таблицы напрямую формируются названия ключевой последовательности (MO_KEY),
первичного ключа (MO_PK), внешних ключей (MO_FK_3, MO_FK_7, ...), триггеров (MO_INS, MO_UPD, ...).

Все изменения данных в таблице MO логируются в таблицу MO_LOG,
история наследования данных хранится в MO_HIS,
при загрузке данных используется промежуточная таблица MO_BUF,
таблицы расширенных свойств стартуют с MO, например MOADDRESS,
таблицы связей стартуют с MO_ххх,
иерархические оглавления стартуют с _MO, или в более поздних версиях с W_MO

Естественно, что при наличии ограничения на длину идентификатора объекта приходится придумывать сокращения
типа Procurement -> PRC, Proposal -> PRS, Supplier -> SPR, но к ним за годы работы сильно привыкаешь.

И конечно надо следить чтобы системные префиксы и суффиксы не попали в число сокращений.

...

Рейтинг:

0 / 0

11.09.2020, 07:23

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997518

Dimkas

Гость

Валерий Юринский

Я бы оформил это так:

Пример был написан в форуме и оформлению не подвергался.
В рабочей системе запросы выглядят примерно так:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

select 
  d.department,
  c.client 
from 
  department_client d_c,
  department d,
  client c 
where 
  d_c.idclient = c.idclient and 
  d_c.iddepartment = d.iddepartment

Запятые в начале строки иногда просятся, но годами мучаюсь и не использую :)

Еще задумался над выбором между IDMO и MO_ID -
ИМХО легче читается вслух именно первый вариант, но возможно у меня многолетняя привычка.

...

Рейтинг:

0 / 0

11.09.2020, 07:27

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997576

ВМоисеев

Участник

Откуда: Редкино

Сообщения: 2 426

Рейтинг: 0 / 0

>softwarer, 8 сен 20, 01:01 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1328925&msg=22193279][22193279]
<
А если так:
1. справочник клиентов - tbl_Client
2. первичный ключ справочника клиентов - pk (или pk_Entity)
3. справочнику льгот - tbl_Privilege
4. первичный ключ справочника льгот - pk (или pk_Entity)
5. в справочнике клиентов внешний ключ на справочник льгот fk_Privilege
или (Ваш 4)
ввести таблицу связи, если она понадобится, назвать tbl_Client_Privilege = (pk_Entity, fk_Client ,fk_Privilege)

...

Рейтинг:

0 / 0

11.09.2020, 11:40

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997625

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

ВМоисеев

А если так:
1. справочник клиентов - tbl_Client

Не раньше, чем Вас начнут звать чел_ВМоисеев.

...

Рейтинг:

0 / 0

11.09.2020, 13:34

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997633

Alibek B

Участник

Сообщения: 3 880

Рейтинг: 0 / 0

У префиксов есть одно удобство — с ними можно не думать о конфликтах с системными именами и зарезервированными словами. Называть таблицы T_USER, например.

...

Рейтинг:

0 / 0

11.09.2020, 13:45

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997660

ВМоисеев

Участник

Откуда: Редкино

Сообщения: 2 426

Рейтинг: 0 / 0

>softwarer, сегодня, 13:34 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1328925&msg=22195366][22195366]
>Не раньше ...
<
Некоторые думали иначе:
Здесь(382) . "ЛИЧНОЕ И СТРОГО СЕКРЕТНОЕ ПОСЛАНИЕ ОТ г-на ЧЕРЧИЛЛЯ МАРШАЛУ СТАЛИНУ".
По сути вопроса - префикс может идентифицировать не только таблицу, но и представление (view), построенном на базе таблицы

...

Рейтинг:

0 / 0

11.09.2020, 14:48

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997717

ChA

Участник

Откуда: Москва

Сообщения: 10 913

Рейтинг: 0 / 0

Alibek B.

Можно и без них не думать о конфликтах, используя стандартные способы экранирования, которые есть практически в любой "нормальной" СУБД. Обычно для этого используются кавычки вокруг имён объектов, т.е., вместо User можно писать "User" и никаких конфликтов. В MS SQL такую же роль могут играть квадратные скобки, например [User]. А учитывая, что объекты легко распределить между схемами, тоже весьма распространённым механизмом, то смысл в префиксах и вовсе отпадает. Не говоря уж о том, что системные объекты и так уже нередко имеют наименование с префиксом.

Некоторые и вовсе городят префиксы, описывающими тип объекта, что-то вроде tbl_AnyName или vue_AnyName, что говорит лишь о неудобстве интерфейса, в котором они работают. Вменяемые средства, как правило, позволяют легко отделить "овнов" от "козлищ" и без таких натужных способов. А в запросе всё равно, что таблица, что представление, всё равно все обращения к таковым объектам в большинстве случаев меняются на "говорящие" псевдонимы(алиасы).

...

Рейтинг:

0 / 0

11.09.2020, 17:11

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997744

egorych

Участник

Откуда: и зачем;

Сообщения: 4 817

Рейтинг: 0 / 0

ВМоисеев

префикс может идентифицировать не только таблицу, но и представление (view), построенном на базе таблицы

особенное удовольствие от такого стандарта кодирования получаешь, когда в процессе жизненного цикла базы таблица превращается в представление, или наоборот :)

...

Рейтинг:

0 / 0

11.09.2020, 18:01

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997862

hVostt

Участник

Сообщения: 18 899

Рейтинг: 0 / 0

Валерий Юринский

Код: plsql

1.
2.
3.
4.
5.
6.
7.

select d.name AS department_name
     , c.name AS client_name 
from department_client d_c
   , department d
   , client c 
where d_c.client_id = c.id 
  and d_c.department_id = d.id

Считаю, что это лучше читается, а значит поможет избежать ошибок.

Но это уже другая тема.

Я бы не сказал, что другая тема.
Если основным инструментом для того, чтобы "избежать ошибок" является форматирование, или наименование полей, то -- что-то не так в датском королевстве.

Если плотно сидишь на одном проекте, вот прям так, до самой грёбаной пенсии, а ещё проект такой, что в нём один пожизненный разработчик, то это как бы работает. А в таком случае, вообще пофиг что и как делать. Можешь свой единоличный стандарт соглашений придумать, не похожий ни на один в мире. Всем до лампочки, ты один же.

А если происходит так, что работаешь на нескольких проектах, имеешь шикарную возможность переходить с проекта на проект, или там в условные 3+/- года менять работу, то это будет так называемый кошмар переназначенных клавиш.

Сидел себе верил, в то, что FK поле должно иметь имя таблицы в названии, как в Христа, а потом бах, на другом проекте не так, и команда вообще не понимает нафига это упало, скажут а вы ещё тип данных батенька в имя поля засуньте, чтоб вообще смешно было :))

Сокращения какие-то, превращающие запрос в эльфийский язык. Сложные правила, которые ещё плохо работают при смене СУБД.

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

...

Рейтинг:

0 / 0

11.09.2020, 23:38

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997938

ВМоисеев

Участник

Откуда: Редкино

Сообщения: 2 426

Рейтинг: 0 / 0

>hVostt, вчера, 23:38 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1328925&msg=22195703][22195703]
>...а вы ещё тип данных батенька в имя поля засуньте, чтоб вообще смешно было :))...
<
Почему смешно?

...

Рейтинг:

0 / 0

12.09.2020, 16:28

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997985

Ennor Tiegael

Участник

Сообщения: 3 069

Рейтинг: 0 / 0

ChA

Alibek B.

Обычно проблемой бывает конфликт не с системными объектами (в MSSQL они в отдельной схеме), а с reserved keywords. Таблицы User, Group, Order - это трэш при кодировании, постоянно квадратные скобки добавлять приходится. Мне проще переводить их в множественное число, всего +1 доп. символ, и тот обычно покрывается Intellisense'ом.

Я как-то писал вьюхи, экспортирующие данные из системы, где одна из ключевых таблиц называлась dbo.Case - мало не показалось.

...

Рейтинг:

0 / 0

12.09.2020, 21:07

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997986

Критик

Участник

Откуда: Москва / Калуга

Сообщения: 35 963

Рейтинг: 0 / 0

GrigoriyFomin

Доброго дня. Подскажите академическое красивое решение именования таблиц и их полей при проектировании базы.
Есть справочник клиентов CLIENTS, ключевое поле CLID, есть справочник льгот BENS, ключевое поле BNID и есть таблица со связью клиента и льгот. Как красиво ее назвать (таких троек таблиц будет много по разным сущностям), и как понятно назвать связывающую таблицу и ее поля (пара клиента и льготы)?

Все в единственном числе.
Для сокращений типа ИНН - использовать транслитерацию.
Регистр - по договорённости.

DIC_CLIENT, ключ ID_CLIENT (если нужно два и больше полей в одной таблице, то ID_CLIENT_что_то_там)
DIC_BENEFIT, ключ ID_BENEFIT
TBL_CLIENT_BENEFIT, ключ ID_CLIENT_BENEFIT identity

FCT_ - для фактов
DM_ - для (денормализованных) витрин данных, куда непосредственно или через отчеты пользователи лезут

первичный ключ - PK_ (лично я использую шаблон, который генерит SSMS)

Всякие варианты с полями, которые просто "ID" делать не нужно, т.к. потом трудно будет применять автоматические средства анализа. Для примера пусть разработчик забабахал:
ID tinyint в одной таблице
ID_CLIENT smallint в другой
гораздо проще найти ошибку типа данных, если названия одинаковы

_id как суффикс не нравится - не позволяет сразу же понять, что это какой-то ключ, нужно дочитать до конца слова )

...

Рейтинг:

0 / 0

12.09.2020, 21:08

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997987

Ennor Tiegael

Участник

Сообщения: 3 069

Рейтинг: 0 / 0

ВМоисеев

Потому, что когда придется поменять тип столбца, придется его и переименовывать заодно. После чего ловить блох по всей БД (и всем клиентским приложениям, работающим с этой базой), если используемые тулзы не умеют делать нормальный Rename / Find All References.

...

Рейтинг:

0 / 0

12.09.2020, 21:11

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39997990

ВМоисеев

Участник

Откуда: Редкино

Сообщения: 2 426

Рейтинг: 0 / 0

>Ennor Tiegael, сегодня, 21:11 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1328925&msg=22195962][22195962]
>Потому, что когда придется поменять тип столбца, придется его и переименовывать заодно...
<Замена типа столбца далеко не простая операция. Если идти на это, то замена имени очевидно (для меня).

>...и всем клиентским приложениям, работающим с этой базой...
<В клиентских приложениях при наименовании объектов стараюсь префиксом показать его тип.

...

Рейтинг:

0 / 0

12.09.2020, 21:49

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39998007

ChA

Участник

Откуда: Москва

Сообщения: 10 913

Рейтинг: 0 / 0

Ennor Tiegael

На мой взгляд, хорошим тоном при написании запросов считается обязательное указание схемы объекта, что обычно снимает проблему с "опасными" наименованиями. Как минимум, это полезно для того, чтобы engine точно знал из какой схемы брать объект, а не подбирал по своему алгоритму. Схема фактически определяет пространство имён. С наименованием полей, в принципе, та же ситуация, только роль схемы тут играет имя таблицы(псевдоним). Без их точного указания есть немалый шанс, что поле будет выбрано тоже "случайно", а вовсе не то, которое подразумевал программист при написании запроса.

...

Рейтинг:

0 / 0

13.09.2020, 00:07

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39998008

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

ChA

На мой взгляд, хорошим тоном при написании запросов считается обязательное указание схемы объекта, что обычно снимает проблему с "опасными" наименованиями.

Не думаю, что указание схемы решит проблему с зарезервированными словами. Хотя, конечно, зависит от синтаксического анализатора. Что касается хорошего тона - думаю, это хороший тон для приложений, размещённых в нескольких схемах. Когда же оно занимает одну схему - практика как минимум спорная, особенно в проектах для внешнего заказчика.

...

Рейтинг:

0 / 0

13.09.2020, 00:22

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39998015

Андрей Юниор

Участник

Откуда: Москва

Сообщения: 194

Рейтинг: 0 / 0

Как мне кажется, всё довольно просто.

Отвечая на исходный вопрос темы, у нас принято добавлять слово "link". Ещё есть какая-то игра слов с RefRef, но я её не помню. Какое именно слово использовать, не столь принципиально. Важно, чтобы связки выделялись.

Дальше очень интересный момент с типичными алиасами таблиц и наименованиями полей. Сегодня 13 сентября 2020 года. Любая IDE имеет автокомплит. А которая не имеет, имеет дополнения c автокомплитом. Поэтому не нужно боятся длинных названий. Надо длинно - пишите длинно. Нужно думать не о том, как бы меньше знаков напечатать (да и не придётся их печатать благодаря автокомплиту). А о том, как это будет читаться в будущем. Вот этот пример из темы (я расставил переносы строк):

Dimkas

Код: plsql

1.
2.
3.
4.
5.
6.
7.

SELECT d.name AS department_name,
       c.name AS client_name
FROM department_client d_c,
     department d,
     client c
WHERE d_c.client_id = c.id
  AND d_c.department_id = d.id

Я бы записал вот так:

Код: plsql

1.
2.
3.
4.
5.
6.
7.

SELECT department.name AS department_name,
       client.name     AS client_name
FROM department_client_link,
     department,
     client
WHERE department_client_link.client_id = client.id
  AND department_client_link.department_id = department.id

В данном примере вообще без алиасов, потому что названия и так прекрасно отражают суть и при этом являются короткими. Зато насколько хорошо это читается! Мне не нужно читать блок FROM, чтобы понять, что происходит в SELECT и WHERE - я могу сразу читать только нужную часть запроса. Мне не нужно запоминать алиасы. Алиас должен отражать суть в конкретном запросе. На этом маленьком примере не совсем очевидно, но на вьюхах по 200 строк кода преимущества полных названий становятся однозначными.

И последний момент с тем, как называть ID в таблицах. Идентификатор таблицы так называть ID. Ссылку на внешнюю таблицу - называть ForeignTable_ID . И на примере выше сразу получаются записи вида department.ID и department_client_link.Department_ID - хоть выглядит длинно, зато читается отлично.

...

Рейтинг:

0 / 0

13.09.2020, 02:15

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39998017

Ennor Tiegael

Участник

Сообщения: 3 069

Рейтинг: 0 / 0

softwarer

ChA

Совершенно верно в том смысле, что имя схемы проблему не решает:

Код: sql

1.
2.
3.
4.

-- Не работает
select top 100 * from dbo.Case c;
-- Работает
select top 100 * from dbo.[Case] c;

Касательно указания схемы - не знаю насчет оракла, но у MSSQL есть некоторые особенности, вследствие которых лучше всегда указывать схему явно, даже если все объекты лежат в дефолтной dbo.

Навскидку, единственный случай, когда отсутствие имени схемы может быть полезно, это если есть несколько одноименных объектов в разных схемах, и нужно, чтобы один и тот же код подхватывал разные объекты в зависимости от текущего пользователя, а точнее, от значения DEFAULT_SCHEMA в его свойствах. Но за мои 20+ лет опыта я ни разу не видел, чтобы этим хоть кто-то пользовался, ибо это те еще грабли - если что-то сломается, концов не найдешь (а менее опытные разрабы даже не будут знать, где искать).

...

Рейтинг:

0 / 0

13.09.2020, 04:42

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#39998020

Alibek B

Участник

Сообщения: 3 880

Рейтинг: 0 / 0

Андрей Юниор

Мне не нужно читать блок FROM, чтобы понять, что происходит в SELECT и WHERE - я могу сразу читать только нужную часть запроса. Мне не нужно запоминать алиасы.

EAV.
Да и без EAV бывает несколько соединений с одной и той же таблицей.

...

Рейтинг:

0 / 0

13.09.2020, 09:04

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#40000686

Валерий Юринский

Участник

Откуда: Москва, "ФОРС Дистрибуция"

Сообщения: 1 357

Рейтинг: 0 / 0

egorych

ВМоисеев

префикс может идентифицировать не только таблицу, но и представление (view), построенном на базе таблицы

Обычно двух-трех- символьным префиксом указывают систему-подсистему,
к которой относится таблицы, view, пакеты, процедуры, функции и другие объекты схемы.

Как уже сегодня заметили: сегодня это таблица, а завтра view.
Editioned view напрямую выполняют функции таблиц.

...

Рейтинг:

0 / 0

20.09.2020, 21:00

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#40000687

Валерий Юринский

Участник

Откуда: Москва, "ФОРС Дистрибуция"

Сообщения: 1 357

Рейтинг: 0 / 0

Dimkas

Валерий Юринский

Приведите, пожалуйста, пример, чтобы публика оценила.

Пример, таблица MO содержит поля:

Лет 20 назад я видел систему, в которой все таблицы и их столбцы имели двухсимвольные имена.
В составе документации была книга, в которой эти названия описывались человеческим языком.

Код: sql

1.
2.
3.
4.

SELECT tk, mb, sn, rt
FROM uy
WHERE nv = 1
  AND vn LIKE 'Отчет%';

Душераздирающее зрелище. :-(

Раньше давали короткие имена для экономии памяти.
Теперь это неактуально.

В современных версиях Oracle идентификаторы длинные (раньше было не более 30 символов).
Предполагаю, что в других СУБД уже тоже больше 30 (128? 255? Больше?).
Поэтому, как минимум, имена ограничений целостности можно назначать очень содержательные.

...

Рейтинг:

0 / 0

20.09.2020, 21:11

| Ответить | Цитировать | Написать

подскажите хорошую практику наименования связанных таблиц

#40000805

Dimkas

Гость

Валерий Юринский

Раньше давали короткие имена для экономии памяти.
Теперь это неактуально.

1. Пример хотелось привести наиболее короткий, для наглядности,
2. Конкретно эта таблица по-русски называется "Медицинская организация" и везде по документации сокращается до "MO",
3. Система стартовала на Oracle 8i :)

В целом к трёхбуквенным сокращениям привыкаешь очень сильно,
они быстро начинают восприниматься как просто термин - все вот эти PRC, PRS, SPR, MNT и т.д. - они ж как родные уже :))

...

Рейтинг:

0 / 0

21.09.2020, 11:26

| Ответить | Цитировать | Написать

25 сообщений из 132, страница 3 из 6

все

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=32&msg=40000687&tid=1539838]:	0ms
get settings:	10ms
get forum list:	13ms
check forum access:	4ms
check topic access:	4ms
track hit:	51ms
get topic data:	12ms
get forum data:	3ms
get page messages:	83ms
get tp. blocked users:	2ms
others:	253ms

total:	435ms