powered by simpleCommunicator - 2.0.48     © 2025 Programmizd 02
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помощь с проектированием БД, клиенты, документы
25 сообщений из 103, страница 4 из 5
Помощь с проектированием БД, клиенты, документы
    #39980049
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
Веселье в Вашем решении начнётся, как только потребуется кинуть внешний ключ на юрика или разобрать "наименование" физика отдельно на фамилию, имя и отчество.

Так все ведь уповают, что "когда понадобится, тогда и сделаем", а на деле "когда понадобится" лепят поверх какой-нибудь костыль из полированной какашки "давайте тогда будем просто ФИО разделять на три части точкой с запятой". А потом пишут сюда же на форум "помогите, христа ради, написать мне такой-то запрос".
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980052
17-77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer,
а тут я уже в каждом конкретном случае буду считать порождаемое кол-во костылей для того или иного решения и выберу наименьшее, ну или как-то так

fkthat
На самом деле три, т.к. еще нужен дискриминатор.

оно у меня уже есть - поле тип

fkthat
Если на клиенте используется ОРМ, то вообще ничего не нужно - давно уже все ОРМы прекрасно мепят подтипы в РБД на наследование классов в коде.

ага, и она сгенерит два класса, а теперь расскажи мне как ты будешь делать:
1. формы списков ЮЛ/ФЛ с фильтрацией, сколько у тебя их будет
2. формы для редактирования ЮЛ/ФЛ и сколько их у тебя будет
3. дроп-даун-лист для выбора истца в деле

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

ээ нее, не передергивай, такого я не предлагал
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980053
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat
Так все ведь уповают, что "когда понадобится, тогда и сделаем"

Это не то чтобы плохое соображение. Вопрос в том, "а сможем ли мы нормально сделать, когда понадобится?". В данном случае в этом есть большие сомнения.
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980056
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
17-77
ага, и она сгенерит два класса

Она сгенерит три класса - один базовый с общими полями и два производных, каждый с полями специфичными именно для каждого из подтипа сущности. А не какое-то непонятное поле "не мышонок, не лягушка, а неведома зверушка" - то ли это название, то ли это ФИО поди разбери.
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980064
17-77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вы не понимаете следующей штуки:
1. если вам понадобилось только в одном месте сделать ссылку только на ЮЛ, значит во всех остальных 10 местах нужна общая ссылка
2. тогда мое решение без доработок выдаст 1 костыль, а в случае с TPC будет 10 костылей
3. если мое решение расширить до TPT тремя таблицами (ЮЛ/ФЛ/ИП), то по идее можно сделать FK на ЮЛ в одном конкретном случае, но надо проверять, я такой фигней не страдал

fkthat
Она сгенерит три класса

да пофик, в базовом будет только ИД, в ФЛ будет фио, в ЮЛ будет name
как ты сделаешь формы и дроп даун?
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980065
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthatхрани телефоны в полях для e-mail

Вот это, кстати, очень интересный вопрос. Как понять, что "это поле для e-mail" если оно
называется, например, "contact"? Прочитать мысли архитектора, который думал, что
"контактовать клиента можно только по e-mail"?.. А делать если у человека больше одного
мейла? А, нет, можете не отвечать, я знаю, это будут поля mail1, mail2, mail3, mail4,
mail5. Ведь именно так предписывает первая нормальная форма. И ни в коем случае нельзя
сомневаться, ведь может родиться ересь о неструктурированном поле "контактная информация",
а это сделает написание спамобота, рассылающего всем клиентам оповещение об отпуске, очень
сложным.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980075
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov
это будут поля mail1, mail2, mail3, mail4, mail5

Конечно, нет, я их все в одно поле запишу, через тройной дефис (чтобы проще парсить было), и пару-тройку телефонов туда же до кучи Я недавно видел такую БД а-ля кастомной CRM, где так телефоны контактов хранились - через точку с запятой. При этом еще то что туда вводилось операторами вообще никак не проверялось и не форматировалось и там запросто можно было встретить какое-нибудь такое значение (прямо в поле "телефон"): "Иванов Иван Иваныч +7 (123) 4526-824; 234-5678"
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980315
Vladimir_84_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вот не заходил, сейчас глянул )) Как всегда споры развели. ) Честно говоря так и не понял, чем плох тот подход, что получился у меня на последней схеме... ИП... Ну так если что не сложно еще одну таблицу для ИП завести. Ведь одному id из общей таблицы будет соответствовать только одна запись в одной из конкретизированных таблиц. Вроде ничего лишнего, в отличие от одной таблицы. И не шибко хитрые запросы то получаются при таком подходе... Вопрос производительности остро не стоит. Что там еще было то... Статус клиента в таблице дело выбирается из combobox-а (истец, ответчик и т.д.), категория дела тоже (гражданское, уголовное...). В таблицах есть текстовое поле Notes, вот туда все что хочется дополнительно можно записать, типа "клиент - говнюк" или "сложно дозвониться, лучше писать смс", или доп. телефон и т.д. Поскольку одномоментно пользователю необходимо работать только с одним клиентом, и пользователь знает какой категории клиент, вот сделал отдельные графические отображения (View) для физ и юр, сортируется все средствами приложения по любому столбцу, соответственно поиск тоже или там, или там, по любому полю. Данные хранятся в модели (Model), вообщем схема "модель-вид". Классы разделены на интерфейс и внутреннюю логику, и так со всеми таблицами, которые нужно отобразить пользователю. Понятно, что практически любую задачу можно решить различными способами, поэтому и не жду, что все здесь к единому мнению придут. Уже начал делать так =) Ещё один момент просто, мне тут предложили сделать так, как на схеме ниже (часть только с клиентами). Не знаю, так лучше что-ли? Ну если брать в расчет, что такое разделение приемлемо и допускается (это я не к категорическим противникам этой идеи =)).
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980332
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Vladimir_84_
Честно говоря так и не понял, чем плох тот подход, что получился у меня на последней схеме...

Да ничем он не плох. Он вполне правилен, разве что сущности неудачно названы. Вы обнаружите это, как только в программе появятся физ. лица, не являющиеся клиентами - например, какие-нибудь там "свидетели".
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980348
Vladimir_84_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarer, Не, сущностей больше не будет, всякие там лица в карточке дела нужны будут только для учета, ну типа, известны их фамилии, ну и в поле заметки можно о них что-нибудь написать если известно и необходимо. Допустим клиент Иванов, физ. лицо, в деле он истец. Ответчиком выступает некий Петров, вот он дал свой тел. номер для связи, ну там решить может миром вопрос, в поле Заметки можно номер занести. Мне этого Петрова вообщем отдельно учитывать не надо. Есть и есть в заметках. Спасибо. А вариант который мне предлагают усиленно, на схеме, что приложил, он хуже, лучше, или все равно? Мне просто как-то аргументировать надо, что хочу сделать как у меня =)
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980363
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Vladimir_84_
А вариант который мне предлагают усиленно, на схеме, что приложил, он хуже, лучше, или все равно?

На схеме определённо неправильны значки бесконечности. В остальном - можно назвать случаи, когда она чуть более удобна, можно назвать случаи, когда она чуть менее удобна, но в целом разница невелика. Я бы сказал так: вариант на схеме предпочтительнее в тех случаях, когда любой атрибут "клиента - физ. лица", являются либо атрибутом "клиента не физ. лица" либо атрибутом "физ. лица не клиента" (ну и про юриков аналогично).
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980373
Vladimir_84_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarer, все понял спасибо. Стрелочки это препод с учебы так нарисовала не верно ))
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980423
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Vladimir_84_
Вот не заходил, сейчас глянул ))

Нет, не так. Надо:

mix_client (id PK, client_type, ...)
phys_client(id PK, ...) foreign key id references mix_client(id)
yur_client(id PK, ...) foreign key id references mix_client(id)

а у тебя выходит, что одно и тоже юр или физ лицо одновременно является несколькими базовыми "просто лицами".
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980445
Vladimir_84_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
fkthat, спасибо. У меня в моей схеме, которая предыдущая так и сделано.
А эту последнюю мне предложили, но я к ней не склоняюсь.
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980490
17-77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Vladimir_84_
вот сделал отдельные графические отображения (View) для физ и юр

что и требовалось доказать, время разработки х2

Vladimir_84_
Статус клиента в таблице дело выбирается из combobox-а (истец, ответчик и т.д.)

не статус клиента (кстати этого поля я не вижу на последней схеме), а сам клиент

Vladimir_84_
Честно говоря так и не понял, чем плох тот подход, что получился у меня на последней схеме...

и помнится там еще триггер какой-то был - это ты свинью подложил разработчику после тебя, прежде чем вносить изменения - надо будет со всем этим разобраться, костыль на костыле, нет чтобы попроще
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980516
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
17-77
все еще смешно?

Вы правы, тут скорее плакать надо. Не умеем написать view, поэтому надо везде писать coalesce и так далее в том же духе.

С вьюшками другая проблема бывает.
У меня все отчеты написаны поверх вью. И недавно получил:
Код: sql
1.
2.
Msg 8623, Level 16, State 1, Line 5
The query processor ran out of internal resources and could not produce a query plan. This is a rare event and only expected for extremely complex queries or queries that reference a very large number of tables or partitions. Please simplify the query. If you believe you have received this message in error, contact Customer Support Services for more information.


Было 25 компаний в базе, стало 60. У каждой компании - свой набор таблиц (60 наборов таблиц - по одному для каждой компании).

По сабжу.
Есть ОДНА сущность - контрагент. Поэтому желательно создать ОДНУ таблицу, где будут храниться общие данные всех контрагентов - и юр лиц, и физиков. Можно сделать еще пару таблиц для атрибутов, специфических для каждого типа контрагентов... Но я бы так не делал. Нет каких то явных плюсов.
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980523
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov
Было 25 компаний в базе, стало 60. У каждой компании - свой набор таблиц (60 наборов таблиц - по одному для каждой компании)

Ну что я могу сказать. Можно ещё каждую неделю делать для каждой компании новый набор таблиц.

s_ustinov
Есть ОДНА сущность - контрагент.

Это верно.

s_ustinov
Поэтому желательно создать ОДНУ таблицу, где будут

А вот это уже не верно. Стоит подумать в сторону "Есть ДРУГАЯ сущность - физическое лицо. ТРЕТЬЯ сущность - организация". И так далее.
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980555
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov
Есть ОДНА сущность - контрагент.

Есть одна абстрактная сущность "Контрагент", а есть её подтипы, например "ИП", "Юрлицо", "Физлицо".
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980570
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
s_ustinov
Было 25 компаний в базе, стало 60. У каждой компании - свой набор таблиц (60 наборов таблиц - по одному для каждой компании)

Ну что я могу сказать. Можно ещё каждую неделю делать для каждой компании новый набор таблиц.

Это навик так работает - так что все претензии к Микрософт. ))

softwarer

s_ustinov
Есть ОДНА сущность - контрагент.

Это верно.

s_ustinov
Поэтому желательно создать ОДНУ таблицу, где будут

А вот это уже не верно. Стоит подумать в сторону "Есть ДРУГАЯ сущность - физическое лицо. ТРЕТЬЯ сущность - организация". И так далее.

В общем случае, это правильно. Если, например, нам нужны еще и контактные лица, то в некоторых случаях желательно понимать, что один и тот же человек может являться директором одного юр лица, главбухом другого и при этом - еще и ИП. :)

Но при решении конкретной задачи мы в любом случае пренебрегаем некоторыми деталями. И для описываемой ТС задачи, как мне кажется, подобными деталями можно пренебречь.
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980575
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat
s_ustinov
Есть ОДНА сущность - контрагент.

Есть одна абстрактная сущность "Контрагент", а есть её подтипы, например "ИП", "Юрлицо", "Физлицо".

Если уж говорить совсем теоретически, то правильнее думать не о подтипах, а об отдельных сущностях.
Есть контрагенты, есть физ лица, есть юр лица. Физ лицо - не подтип контрагента, а отдельная сущность. Если те же уведомления по почте автоматом рассылать или с днем рождения поздравлять - то для юр лица надо хранить ссылки на контактных лиц (директор, главбух, юрист, секретарь и т.д.).
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980585
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov
Если уж говорить совсем теоретически, то правильнее думать не о подтипах, а об отдельных сущностях.
Есть контрагенты, есть физ лица, есть юр лица. Физ лицо - не подтип контрагента, а отдельная сущность. Если те же уведомления по почте автоматом рассылать или с днем рождения поздравлять - то для юр лица надо хранить ссылки на контактных лиц (директор, главбух, юрист, секретарь и т.д.).

Физлицо это отдельная сущность, любой экземпляр которой при этом одновременно является экземпляром сущности Контрагент - это и есть субтипизация. В IDEF1x для такого даже существует специальная нотация.
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980586
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat
s_ustinov
Если уж говорить совсем теоретически, то правильнее думать не о подтипах, а об отдельных сущностях.
Есть контрагенты, есть физ лица, есть юр лица. Физ лицо - не подтип контрагента, а отдельная сущность. Если те же уведомления по почте автоматом рассылать или с днем рождения поздравлять - то для юр лица надо хранить ссылки на контактных лиц (директор, главбух, юрист, секретарь и т.д.).

Физлицо это отдельная сущность, любой экземпляр которой при этом одновременно является экземпляром сущности Контрагент - это и есть субтипизация. В IDEF1x для такого даже существует специальная нотация.


С чего вдруг
Физлицо это отдельная сущность, любой экземпляр которой при этом одновременно является экземпляром сущности Контрагент
?

Вполне может быть физ лицо - юрист компании клиента (контактное лицо), который сам по себе контрагентом не является.

Если уж создавать в базе сущности "Физ лицо" и "Юр лицо", то не как подтипы сущности "Контрагент", а как отдельные сущности.
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980693
Vladimir_84_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
17-77
Vladimir_84_
вот сделал отдельные графические отображения (View) для физ и юр

что и требовалось доказать, время разработки х2

Vladimir_84_
Статус клиента в таблице дело выбирается из combobox-а (истец, ответчик и т.д.)

не статус клиента (кстати этого поля я не вижу на последней схеме), а сам клиент

Vladimir_84_
Честно говоря так и не понял, чем плох тот подход, что получился у меня на последней схеме...

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


Да, время разработки штука такая... Если хочется быстро, то не факт, что будет хорошо =) Ну будет у меня одна таблица. Я одно представление что-ли сделаю со всеми полями и физ и юр, и где-то галочкой кто это? Ну смотреться это будет мне кажется не очень. Так что хоть и из одной таблицы, но придется выбирать информацию, чтобы клиенту показать, что надо заполнить. Так что тоже кодить. А исходя из предметной области скажу, что юристы с компьютерами тупые вообще, им покажи кучу полей, они заполнят что-нибудь, типа огрн для физ. лица. =) Шучу, но случайно можно тыкнуть не туда. Тут еще проверки надо ставить всякие или блокировать элементы ввода, так что не быстрее и не проще.
Сам клиент выбирается из combobox-а, или не выбирается, если сразу после заполнения его карточки переходишь к новому делу. Я не стал все поля прописывать, мне подсказка по направлению нужна была.
Триггеров не будет, я понял, не советуют.

s_ustinov

В общем случае, это правильно. Если, например, нам нужны еще и контактные лица, то в некоторых случаях желательно понимать, что один и тот же человек может являться директором одного юр лица, главбухом другого и при этом - еще и ИП. :)

Но при решении конкретной задачи мы в любом случае пренебрегаем некоторыми деталями. И для описываемой ТС задачи, как мне кажется, подобными деталями можно пренебречь.


Я вот подумал, зачем выделять отдельно всяких директоров, бухгалтеров, представителей... И не придумал. Исходя из моей задачи, представитель указывается просто, да и все... Зачем это все хранить отдельно?
И вот про "пренебрегаем деталями" я согласен абсолютно, начитался форума, тут некоторые чуть не каждую запятую куда-то выносить хотят =) Теория теорией, но здравый смысл должен быть ))
Я вот сейчас это пытаюсь реализовать, пытался, чтобы дата нормально сохранялась, ну типа ДР клиента, или дату выдачи паспорта... Ну чтобы не дефолтное значение, что фреймворк подставляет, а допустим "No date", и чтобы потом загружалось и проверялось и пр. Так вот задолбался этой фигней заниматься и пришел к выводу, а нафиг мне вообще допустим поле "Дата выдачи паспорта", только что так делают? =) Но это же не для МФЦ программа или кому еще это надо.
Я вообще много полей поудаляю нафиг, я знаю, что и половину не заполнят... Кстати спасибо комраду Dimitry Sibiryakov, он в этом плане мне помог осознать ))) Короче надо коротенько и по делу).
Вообще спасибо всем, я услышал, опыта прибавилось =)
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980700
Vladimir_84_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
[quot Vladimir_84_#22168925]
17-77


что и требовалось доказать, время разработки х2

не статус клиента (кстати этого поля я не вижу на последней схеме), а сам клиент

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


Да, время разработки штука такая... Если хочется быстро, то не факт, что будет хорошо =) Ну будет у меня одна таблица со всеми полями, и физ и юр, и где-то галочкой кто это. Но придется все равно выбирать информацию, чтобы пользователю показать, что надо заполнить. Или оставить одно окно со всеми реквизитами... Смотреться это будет мне кажется не очень. Так что в любом случае кодить. А исходя из предметной области скажу, что юристы с компьютерами тупые вообще, им покажи кучу полей, они заполнят что-нибудь, типа огрн для физ. лица. =) Шучу, но случайно можно тыкнуть не туда. Тут еще проверки надо ставить всякие или блокировать элементы ввода, так что не быстрее и не проще.
Сам клиент выбирается из combobox-а, или не выбирается, если сразу после заполнения его карточки переходишь к новому делу. Я не стал все поля прописывать, мне подсказка по направлению нужна была.
Триггеров не будет, я понял, не советуют.

s_ustinov

В общем случае, это правильно. Если, например, нам нужны еще и контактные лица, то в некоторых случаях желательно понимать, что один и тот же человек может являться директором одного юр лица, главбухом другого и при этом - еще и ИП. :)

Но при решении конкретной задачи мы в любом случае пренебрегаем некоторыми деталями. И для описываемой ТС задачи, как мне кажется, подобными деталями можно пренебречь.


Я вот подумал, зачем выделять отдельно всяких директоров, бухгалтеров, представителей... И не придумал. Исходя из моей задачи, представитель указывается просто, да и все... Зачем это все хранить отдельно?
И вот про "пренебрегаем деталями" я согласен абсолютно, начитался форума, тут некоторые чуть не каждую запятую куда-то выносить хотят =) Теория теорией, но здравый смысл должен быть ))
Я вот сейчас это пытаюсь реализовать, пытался, чтобы дата нормально сохранялась, ну типа ДР клиента, или дату выдачи паспорта... Ну чтобы не дефолтное значение, что фреймворк подставляет, а допустим "No date", и чтобы потом загружалось и проверялось и пр. Так вот задолбался этой фигней заниматься и пришел к выводу, а нафиг мне вообще допустим поле "Дата выдачи паспорта", только что так делают? =) Но это же не для МФЦ программа или кому еще это надо.
Я вообще много полей поудаляю нафиг, я знаю, что и половину не заполнят... Кстати спасибо комраду Dimitry Sibiryakov, он в этом плане мне помог осознать ))) Короче надо коротенько и по делу).
Вообще спасибо всем, кто помог участием, поскольку с этой сферой я недавно только столкнулся, я всех услышал, опыта прибавилось =)
...
Рейтинг: 0 / 0
Помощь с проектированием БД, клиенты, документы
    #39980713
Vladimir_84_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Не знаю, что за хрень с двумя сообщениями, извините. Кнопку удалить не нашёл.
...
Рейтинг: 0 / 0
25 сообщений из 103, страница 4 из 5
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помощь с проектированием БД, клиенты, документы
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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