ReSQL.ru
     
powered by simpleCommunicator - 2.0.47     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / подскажите хорошую практику наименования связанных таблиц
132 сообщений из 132, показаны все 6 страниц
  все  
подскажите хорошую практику наименования связанных таблиц
    #39996327
GrigoriyFomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GrigoriyFomin
Гость
Доброго дня. Подскажите академическое красивое решение именования таблиц и их полей при проектировании базы.
Есть справочник клиентов CLIENTS, ключевое поле CLID, есть справочник льгот BENS, ключевое поле BNID и есть таблица со связью клиента и льгот. Как красиво ее назвать (таких троек таблиц будет много по разным сущностям), и как понятно назвать связывающую таблицу и ее поля (пара клиента и льготы)?
...
Рейтинг: 0 / 0
07.09.2020, 19:53
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996337
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
CLIENTS_BEANS
CLID
BNID

Особо извращённые MS SQL пользователи могут использовать [Clients<->Bens].
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
07.09.2020, 20:37
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996341
GrigoriyFomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GrigoriyFomin
Гость
Тогда надо алиасы таблиц указывать в запросе, так как поля имеют одинаковое название.
...
Рейтинг: 0 / 0
07.09.2020, 20:59
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996342
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ennor Tiegael
Участник
GrigoriyFomin,

Алиасы таблиц в запросах лучше указывать всегда.
...
Рейтинг: 0 / 0
07.09.2020, 21:06
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996366
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Злой Бобр
Участник
GrigoriyFomin
... академическое красивое решение ...

Нету такого. Каждый лепит от балды.
Я видел базу где таблицы были типа А001, В07, ... Ну и поля примерно такие же. И никто не возмущался. Работает да и хрен с ним.
...
Рейтинг: 0 / 0
07.09.2020, 23:39
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996370
GrigoriyFomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GrigoriyFomin
Гость
Злой Бобр
GrigoriyFomin
... академическое красивое решение ...

Нету такого. Каждый лепит от балды.
Я видел базу где таблицы были типа А001, В07, ... Ну и поля примерно такие же. И никто не возмущался. Работает да и хрен с ним.

А потом придет новый прогер и будет на хабре выкладывать скрины с описаниеми сего идиотизма под одобряющее улюлюканье коллег по цеху, который будут предлагать свои решения )
...
Рейтинг: 0 / 0
08.09.2020, 00:12
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996373
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
GrigoriyFominпридет новый прогер и будет на хабре выкладывать скрины с описаниеми сего идиотизма

Ну, это сначала должно вырасти поколение нубов, не слышавших про "базу Болтика".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
08.09.2020, 00:29
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996376
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
GrigoriyFomin
Подскажите академическое красивое решение именования таблиц и их полей при проектировании базы

Во-первых, справочник клиентов, как и другие таблицы, назвать в единственном числе - client.
Во-вторых, его первичный ключ назвать client_id.
В-третьих, справочнику льгот дать нормальное и подходящее по бизнес-логике название в единственном числе. Например, privilege. Его первичный ключ, соответственно, назвать privilege_id.
В-четвёртых, таблицу связи, если она понадобится, назвать client_privilege.
...
Рейтинг: 0 / 0
08.09.2020, 01:01
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996382
GrigoriyFomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GrigoriyFomin
Гость
Dimitry Sibiryakov

GrigoriyFominпридет новый прогер и будет на хабре выкладывать скрины с описаниеми сего идиотизма

Ну, это сначала должно вырасти поколение нубов, не слышавших про "базу Болтика".

мне 38, програмлю 25 лет, начиная с ZX Spectrum и я не слышал про базу болтика ) гугль тоже ничего не выдал. ЧЯДНТ! Я комплексую!
...
Рейтинг: 0 / 0
08.09.2020, 01:38
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996383
GrigoriyFomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GrigoriyFomin
Гость
В-четвёртых, таблицу связи, если она понадобится, назвать client_privilege.
как показывает опыт - сложно отлаживать запросы, содержащие такие длинные названия таблиц/полей. Так, справочник контрагентов CONTRAGENTS проще назвать CAS, сотрудников EMPS, ну и в таком роде.
...
Рейтинг: 0 / 0
08.09.2020, 01:42
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996399
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
crutchmaster
Участник
softwarer
Во-вторых, его первичный ключ назвать client_id.

И получится client.client_id. Зачем? Почему не делать все первичные поля id, а внешние - client_id.
...
Рейтинг: 0 / 0
08.09.2020, 06:40
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996400
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
crutchmaster
Участник
GrigoriyFomin,

У нас - так: первичный ключ - везде id, внешний ключ - fk_имя_таблицы, связанные таблицы table1xtable2, если совсем туго с именем.
...
Рейтинг: 0 / 0
08.09.2020, 06:42
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996405
Dimkas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimkas
Гость
crutchmaster
softwarer
Во-вторых, его первичный ключ назвать client_id.

И получится client.client_id. Зачем? Почему не делать все первичные поля id, а внешние - client_id.


Могу пояснить свою собственную логику для такого случая:
Вот есть таблица клиентов - client(id integer, name varchar),
рядом таблица подразделений - department(id integer, name varchar)
Как будет выглядеть таблица "Связь клиентов и подразделений"?
Наверное что-то типа client_department(id integer, client_id integer, department_id integer), так?

А как выглядит запрос списка департаментов и обслуживаемых ими клиентов?
Очевидно
Код: 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



Так вот в этом запросе есть два момента, которых лично мне хочется избежать:
1. Лишнее переименование d.name в department_name - хочется обойтись без переименования вообще.
2. Связь вида d_c.client_id = c.id - где связываемые поля имеют разные названия, хочется связывать поля с одинаковыми названиями.

Поэтому у нас все таблицы, в которых хранятся сущности, имеют структуру вида
client(idclient integer, client varchar, ...)
и поля-ссылки на таблицу client всегда начинаются с idclient,
И только если клиентов в одной таблице больше одного, то используем что-то типа idclient_1, idclient_2,...

Общее правило у нас такое - одинаковые названия могут и ДОЛЖНЫ иметь только те поля, которые можно сравнивать между собой.
А если все ключи во всех таблицах имеют название ID, то в какой-то момент можно подумать, что имеет смысл их сравнивать между собой.
...
Рейтинг: 0 / 0
08.09.2020, 07:56
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996414
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
crutchmaster
Участник
Dimkas
Общее правило у нас такое - одинаковые названия могут и ДОЛЖНЫ иметь только те поля, которые можно сравнивать между собой.

Вот это интересно в плане автоматизации построения запросов.
...
Рейтинг: 0 / 0
08.09.2020, 08:39
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996426
Dimkas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimkas
Гость
crutchmaster,
именно потребность в автоматизации построения запросов и породила решение

"знаешь идентификатор таблицы - знаешь о ней почти всё"
...
Рейтинг: 0 / 0
08.09.2020, 09:25
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996436
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
GrigoriyFomin
как показывает опыт - сложно отлаживать запросы, содержащие такие длинные названия таблиц/полей.

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

crutchmaster
Почему не делать все первичные поля id

Потому что никто не пользуется полными названиями таблиц как префиксами в запросах, а при коротких алиасах строчки типа

Код: plsql
1.
c.client_id = s.client_id


оказываются существенно удобнее, нежели

Код: plsql
1.
c.id = s.client_id


, особенно в сложных запросах.
...
Рейтинг: 0 / 0
08.09.2020, 09:50
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996592
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ъъъъъ
Гость
softwarer
...

Код: plsql
1.
c.client_id = s.client_id


оказываются существенно удобнее, нежели

Код: plsql
1.
c.id = s.client_id


...

А мне кажется, что наоборот, второй вариант удобнее.
...
Рейтинг: 0 / 0
08.09.2020, 14:44
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996616
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
softwarer
В-четвёртых, таблицу связи, если она понадобится, назвать client_privilege.
и как тогда назвать первичный ключ у этой таблицы? client_privilege_id? как то заковыристо, на мой вкус
...
Рейтинг: 0 / 0
08.09.2020, 16:04
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996617
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
egorych
и как тогда назвать первичный ключ у этой таблицы?

Первичный ключ у этой таблицы назвать client_privilege_pk. А то поле id, о котором Вы говорите, чаще всего в ней вообще не нужно.
...
Рейтинг: 0 / 0
08.09.2020, 16:07
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996624
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
softwarer
Первичный ключ у этой таблицы назвать client_privilege_pk. А то поле id, о котором Вы говорите, чаще всего в ней вообще не нужно.
практика показывает обратное. Вырожденные связи, в которых есть только два атрибута-ссылки на связываемые сущности - живут обычно в воспалённом воображении ЧАЛа, в реальности, если рассматривать конкретный пример связи клиентов с действующими для них льготами, то, как минимум, нам потребуются ещё дата начала действия льготы, дата окончания действия льготы, ссылка на документ, на основании которого клиенту установлена эта льгота и т.д. Со всем этим придётся как-то взаимодействовать, и работать с id в такой таблице удобней, чем с составным ключом.
...
Рейтинг: 0 / 0
08.09.2020, 16:19
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996626
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
egorych
Вырожденные связи, в которых есть только два атрибута-ссылки на связываемые сущности - живут обычно в воспалённом воображении ЧАЛа

В воспалённом воображении ЧАЛа всё должно иметь идентификатор, так что к нему близка как раз Ваша точка зрения. В остальном не вижу смысла здесь и с таким стартом тратить время на подобное обсуждение.
...
Рейтинг: 0 / 0
08.09.2020, 16:22
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996632
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
Использую следующие правила
1. Никакой транслитерации, только правильное английское название сущности,
.т.к. прочитает любой человек, будь то испанец или японец
2. Никаких сокращений, никому не интересно ломать голову, что это вы зашифровали в таблице,
а прежде всего вы сами быстро вспомните, что в этой таблице хранится.
3. В единственном числе, поскольку множественное число, как правило, в английском языке формируется добавлением -s,
помимо этого в английском языке есть исключения при формировании множественного числа, т.ч. отказавшись от множественного числа мы убираем лингвистические проблемы, и облегчаем себе всяческую автоматизацию.
4. Для отношений многие-ко-многим использую таблицы с названиями вида: BRANCH_STAFF
5. Для таблиц главная, подчинённая использую названия вида PATIENT ; PATIENT$SERVICE
6. Для всех таблиц (за исключением таблиц отношений многие-ко-многим) обязательно создаю первичный ключ с именем "Х"+"название таблицы", например в таблицах PATIENT и PATIENT$SERVICE будут соответственно первичные ключи XPATIENT и XPATIENT$SERVICE, для подчиненной таблицы будет ещё внешний ключ с названием первичного ключа главной таблицы, соответственно XPATIENT. Не использую для именования суффиксы-префиксы "_ID" , "ID", поскольку на мой взгляд они сильно засоряют запросы и замедляют восприятие текста. Проводил тестирование студентов, замедление восприятия текста около 20%.
Букву Х выбрал исходя из максимальной "бедности" этой буквы в английском языке.
7. В таблицах отношений многие-ко-многим присутствуют внешние ключи имеющие названия первичных ключей связываемых таблиц, например
Код: sql
1.
2.
3.
CREATE TABLE BRANCH_STAFF (
    XBRANCH   DX /* DX = INTEGER NOT NULL */,
    XSTAFF    DX /* DX = INTEGER NOT NULL */....
...
Рейтинг: 0 / 0
08.09.2020, 16:39
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996638
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
zeon11
5. Для таблиц главная, подчинённая использую названия вида PATIENT ; PATIENT$SERVICE

Символ $ я предпочитаю зарезервировать для префикса. Когда количество таблиц в приложении переваливает за сотню и начинает бежать к тысячам, их алфавитная сортировка становится неудобной и список превращается в беспорядочную свалку. В этом случае здорово помогает введение промежуточного уровня иерархии, "группы таблиц", который я предпочитаю строить, добавляя префикс предметной области. Скажем, WH$SOMETHING - данные склада, а MAP$OTHERTHING - что-то, имеющее отношение к картам.

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

zeon11
6. Для всех таблиц (за исключением таблиц отношений многие-ко-многим) обязательно создаю первичный ключ с именем "Х"+"название таблицы"

Нарушаете логику пунктов 1-2.

zeon11
поскольку на мой взгляд они сильно засоряют запросы и замедляют восприятие текста. Проводил тестирование студентов, замедление восприятия текста около 20%.

Любопытно, что именно Вы называете "скоростью восприятия" и как её замеряли.
...
Рейтинг: 0 / 0
08.09.2020, 16:53
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996653
Сотрудник Главного Управления
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сотрудник Главного Управления
Участник
GrigoriyFomin
CLIENTS

Тоже не понимаю этой фигни.
Во многих книгах по БД рекомендуется называть таблицы именем предмета (сущности) во множественном числе. Да и Microsoft рекомендует использовать множественное число, и все учебные БД от микрософта этот метод используют. В рекомендациях по проектированию REST API тоже советуют употреблять множественное число в адресах ресурсов.
Я вот всегда использую единственное число и никаких неудобств не ощущаю от этого.
...
Рейтинг: 0 / 0
08.09.2020, 17:24
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996656
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Сотрудник Главного Управления
Во многих книгах по БД рекомендуется называть таблицы именем предмета (сущности) во множественном числе.

Это действительно чуть лучше с точки зрения восприятия текста. Одиночные значения называются в единственном числе, коллекции значений (в том числе таблицы) - во множественном, всё логично. В принципе, можно даже навесить определённое правило, мол подчинённая таблица называется CLIENT_PRIVILEGES (льготы клиента), а развязка называется CLIENTS_PRIVILEGES (клиенты - льготы).

Но эти соображения оказываются менее важными, чем удобства именования в единственном числе, в первую очередь автоматизм получения названия поля из названия таблицы.
...
Рейтинг: 0 / 0
08.09.2020, 17:28
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996658
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
softwarer,
Раньше тоже делил таблицы по группам сущностей, но потом пришли "муки творчества".
Поясню. У меня была информационная система по торговле фруктами. Параллельно создал чисто медицинскую
информационную систему (МИС). Потом попросили на медицинскую информационную систему "навесить" материальное обеспечение (лекарственное, операционное), лечебное питание. Самое лучшее, что придумал - слить базы в одну, соответственно появились таблицы относящиеся к условно назовем "торговле" и "медицине", все мои красивые префиксы стали совсем не "красивые", "лезли в глаз". Ну и почикал все префиксы.
По поводу студентов - разделил новую группу на две части, создал две идентичные БД с именованием "Х", и с именованием "_ID",
попросил написать несколько идентичных запросов на связи нескольких таблиц, среднее время на написание текстов запросов и подсчитал.
Кстати, там-же выяснил, что если связывать таблицы со связью вида " ... a.id = b.staff_id and ..." делают ошибки, связывают не те таблицы, запрос выполняется, а в результатах каша. А если связывать таблицы связью вида " ... a.staff_id = b.staff_id and ...",
то ошибок вообще нет, связывают на автомате правильно.
...
Рейтинг: 0 / 0
08.09.2020, 17:31
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996661
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ъъъъъ
Гость
У меня одна табличка во множественном числе: Users.
Ибо в единственном - в FB нельзя. :)
...
Рейтинг: 0 / 0
08.09.2020, 17:42
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996664
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
zeon11
все мои красивые префиксы стали совсем не "красивые", "лезли в глаз"

Вот тут, мне кажется, вопрос в логике выбора префиксов. Потому что этот пример хорошо ложится в то, что я сказал про префиксы по предметным областям; при удачном выборе они бы вообще идеально слились. И модульность я рассматриваю как раз как серьёзный аргумент в пользу этого подхода; появляется возможность модульно разрабатывать систему (разделяя её вот такими префиксами) и как угодно выделять-комбинировать.

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

zeon11
По поводу студентов - разделил новую группу на две части, создал две идентичные БД с именованием "Х", и с именованием "_ID",попросил написать несколько идентичных запросов на связи нескольких таблиц, среднее время на написание текстов запросов и подсчитал.

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

В общем, я не переоценивал бы такое измерение.

zeon11
Кстати, там-же выяснил, что если связывать таблицы со связью вида " ... a.id = b.staff_id and ..." делают ошибки, связывают не те таблицы, запрос выполняется, а в результатах каша. А если связывать таблицы связью вида " ... a.staff_id = b.staff_id and ...", то ошибок вообще нет, связывают на автомате правильно.

Более грамотные люди в обоих случаях справляются. Но в целом я согласен, когда я выше сказал про то, что такие строчки лучше, я имел в виду именно этот аспект. Их легче надёжно написать и легче глазами увидеть, что всё в порядке.
...
Рейтинг: 0 / 0
08.09.2020, 17:51
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996666
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
ъъъъъ
У меня одна табличка во множественном числе: Users.
Ибо в единственном - в FB нельзя. :)


Дарю: exercist

(Если что, тут игра слов)
...
Рейтинг: 0 / 0
08.09.2020, 17:56
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996672
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
softwarer,
да, и в том числе "автокомплита - достаточно ткнуть 'X'
это тоже даёт ускорение. Мы-же знаем, что связывать можно только по ключам, пишем с десяток таблиц, даем им алиасы,
а потом начинаем "вязать" свитер запрос а.x.... = b.x.... . А чтобы быстро "вязать", не вспоминать названия таблиц,
нужно чтобы индексные поля начинались одинаково, например с "ID_", по мне уже слишком громоздко, три символа тратится!
Вот и выбрал символ "Х", слов на "Х" практически в английском языке нет (в отличие от русского ;-)
...
Рейтинг: 0 / 0
08.09.2020, 18:12
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996674
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
zeon11
нужно чтобы индексные поля начинались одинаково, например с "ID_", по мне уже слишком громоздко, три символа тратится!

Наиболее важная и одновременно наиболее медленная часть процесса разработки называется "думать". Именно её следует оптимизировать для достижения наилучшего результата. Когда речь заходит о скорости набора текста - это означает, что подразумеваются столь простые ситуации, в что голова в их решении в принципе не участвует. И методики, выработанные и оптимизированные для таких ситуаций, становятся неэффективными, как только голову таки приходится включить.
...
Рейтинг: 0 / 0
08.09.2020, 18:24
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996690
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
egorych
softwarer
Первичный ключ у этой таблицы назвать client_privilege_pk. А то поле id, о котором Вы говорите, чаще всего в ней вообще не нужно.
практика показывает обратное. Вырожденные связи, в которых есть только два атрибута-ссылки на связываемые сущности - живут обычно в воспалённом воображении ЧАЛа, в реальности, если рассматривать конкретный пример связи клиентов с действующими для них льготами, то, как минимум, нам потребуются ещё дата начала действия льготы, дата окончания действия льготы, ссылка на документ, на основании которого клиенту установлена эта льгота и т.д. Со всем этим придётся как-то взаимодействовать , и работать с id в такой таблице удобней, чем с составным ключом.

egorych,
тут, в данном конкретном случае, что Вы привели, вы увидели отношение многие-ко-многим, и решили натолкать туда ещё всякого барахла, но не увидели, что задача с барахлом "тянет" на 6НФ, соответственно тут лучше создать новую сущность, назовем её например EXEMPTION, соответственно первичный ключ таблицы будет называться EXEMPTION_ID, внешние ключи CLIENT_ID, PRIVILEGE_ID, ну и "до кучи" DOCUMENT_ID, а также поля DATE_BEGIN, DATE_END и т.д.
и тогда не придётся "как-то взаимодействовать".
...
Рейтинг: 0 / 0
08.09.2020, 19:07
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996705
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
zeon11
тут лучше создать новую сущность, назовем её например EXEMPTION
это хорошо, когда можно придумать однословное название для такой сущности. Бывают и более заковыристые случаи, вроде "группы привилегированных клиентов, входящие в группы рассылки электронной почты", замучаешься придумывать вменяемое короткое название ))
я леплю ID как имя первичного ключа во всех таблицах, где он уместен, хотя аргументы ув. авторов "если связывать таблицы связью вида " ... a.staff_id = b.staff_id and ...", то ошибок вообще нет, связывают на автомате правильно" и " Их легче надёжно написать и легче глазами увидеть, что всё в порядке" выглядят сильно, бессмысленно их оспаривать.
...
Рейтинг: 0 / 0
08.09.2020, 20:25
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996721
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ъъъъъ
Гость
Во! Имя поля PK в форме <ИмяСущности>_id в FireBird позволяет использовать NATURAL джойн!
...
Рейтинг: 0 / 0
08.09.2020, 21:41
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996722
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Использование natural join в продуктовом коде лично я склонен премировать. Тоже натурально. А точнее - большим анальным дилдо, становящимся б/у прямо в ходе вручения, если можно его так назвать.
...
Рейтинг: 0 / 0
08.09.2020, 21:44
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996725
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ъъъъъ
Гость
softwarer,

это да, но ведь появляется возможность. :)
...
Рейтинг: 0 / 0
08.09.2020, 21:54
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996792
Alibek B
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alibek B
Участник
zeon11

1. Никакой транслитерации, только правильное английское название сущности,
.т.к. прочитает любой человек, будь то испанец или японец

И каким будет «правильное английское название сущности» для ИНН, ОСАГО, ФИО?
...
Рейтинг: 0 / 0
09.09.2020, 09:23
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996795
Сотрудник Главного Управления
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сотрудник Главного Управления
Участник
Alibek B.,

ФИО - это не сущность, это атрибуты сущности "Person"

FirstName
SurName
Patronymic
...
Рейтинг: 0 / 0
09.09.2020, 09:34
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996813
Alibek B
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alibek B
Участник
Если ФИО приходит откуда-то извне, то это будет отдельное поле ФИО.
Разбивать его на составляющие не стоит, автоматически это сделать не всегда возможно.
...
Рейтинг: 0 / 0
09.09.2020, 10:24
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996814
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
Alibek B.
zeon11

1. Никакой транслитерации, только правильное английское название сущности,
.т.к. прочитает любой человек, будь то испанец или японец

И каким будет «правильное английское название сущности» для ИНН, ОСАГО, ФИО?


Всё есть, если поискать
https://englishfull.ru/znat/inn-po-angliyski.html

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

Ну и по поводу ФИО.
По хорошему чтобы правильно нормализовать ФИО нужно как минимум три таблицы: Таблица имен, таблица отчеств, Таблица фамилий
При определённых требованиях, я так и делаю.
...
Рейтинг: 0 / 0
09.09.2020, 10:26
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996816
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
zeon11
По хорошему чтобы правильно нормализовать ФИО нужно как минимум три таблицы: Таблица имен, таблица отчеств, Таблица фамилий

Я всегда с удовольствием наблюдаю, как в такие структуры ложится Пабло Диего Хосе Франсиско де Паула Хуан Непомучено Мария де лос Ремедиос Сиприано де ла Сантисима Тринидад Мартир Патрисио Руис и Пикассо.
...
Рейтинг: 0 / 0
09.09.2020, 10:29
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996818
Alibek B
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alibek B
Участник
zeon11

Всё есть, если поискать
https://englishfull.ru/znat/inn-po-angliyski.html


Лучше использовать транслит, чем подобное.
ОКОНХ (Общероссийский Классификатор Отраслей Народного Хозяйства) — OKONKh (All-Russ­ian Clas­si­fi­er of Econ­o­my Branch­es)
ОКПО (Общероссийский Классификатор Предприятий и Организаций) — OKPO (All-Russ­ian Clas­si­fi­er of Enter­pris­es and Orga­ni­za­tions)
СНИЛС (Страховой Номер Индивидуального Лицевого Счёта) — Insur­ance Num­ber of Indi­vid­ual Ledger Account
...
Рейтинг: 0 / 0
09.09.2020, 10:31
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996820
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
softwarer
zeon11
По хорошему чтобы правильно нормализовать ФИО нужно как минимум три таблицы: Таблица имен, таблица отчеств, Таблица фамилий

Я всегда с удовольствием наблюдаю, как в такие структуры ложится Пабло Диего Хосе Франсиско де Паула Хуан Непомучено Мария де лос Ремедиос Сиприано де ла Сантисима Тринидад Мартир Патрисио Руис и Пикассо.


Хе-хе-хе! А ведь я специально про нормализацию ФИО тут загнул! Знал, что вспомнят! Ждал, кто про нашего бедного Пабло Диего и т.д. напомнит. Его, бедняжку, уже лет как 10 по этому форуму мусолят!
...
Рейтинг: 0 / 0
09.09.2020, 10:41
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996827
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
softwarer
zeon11
По хорошему чтобы правильно нормализовать ФИО нужно как минимум три таблицы: Таблица имен, таблица отчеств, Таблица фамилий

Я всегда с удовольствием наблюдаю, как в такие структуры ложится Пабло Диего Хосе Франсиско де Паула Хуан Непомучено Мария де лос Ремедиос Сиприано де ла Сантисима Тринидад Мартир Патрисио Руис и Пикассо.


А если серьёзно, то тут три таблицы: первая - Personnel в которой только одно поле Personnel_ID, вторая таблица имен и третья таблица отношений многие-ко-многим связывающая эти две таблицы, причем в таблице связи есть поле, определяющее последовательность имен. С этой структурой можно хранить и наши ФИО, а также ФИО с окончаниями -оглы, -кызы, -оол и т.д.
...
Рейтинг: 0 / 0
09.09.2020, 11:05
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996834
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
zeon11
причем в таблице связи есть поле, определяющее последовательность имен.

И поле, определяющее тип конкретной частицы имени / роль в полном имени. Потому что если какая-нибудь процедура сократит "Вишванатан Ананд" до "В. Ананд", а "Полад Бюль-Бюль оглы" - до "П. Б. оглы" - это будет не совсем правильно
...
Рейтинг: 0 / 0
09.09.2020, 11:24
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996848
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
softwarer
zeon11
причем в таблице связи есть поле, определяющее последовательность имен.

И поле, определяющее тип конкретной частицы имени / роль в полном имени. Потому что если какая-нибудь процедура сократит "Вишванатан Ананд" до "В. Ананд", а "Полад Бюль-Бюль оглы" - до "П. Б. оглы" - это будет не совсем правильно

Да, согласен. Таблица чем удобна? Тем, что быстро можем определить правила изменения, например, имени. Предположим, заказчику неожиданно понадобилось транслитерировать имена, например в китайский язык. Если мы храним ФИО как обычно принято в одной строке, то эта новая задача поставит нас в тупик, запаримся реализовывать. А если данные нормализованы, то мы просто в таблицу имён добавляем поле, хранящее нужное нам преобразование. И всё! преобразовываем существующее поле ИМЯ в новое поле КИТАЙСКОЕ_ИМЯ, меняем в результирующем запросе поле ИМЯ на КИТАЙСКОЕ_ИМЯ и рассылаем письма китайцам. На всё-про-всё 30 минут.
...
Рейтинг: 0 / 0
09.09.2020, 11:43
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39996887
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
crutchmaster
Участник
zeon11
Таблица чем удобна?

Чтобы не навводили туда Аркадия, Арадия и Акрадия в первую очередь. Если бухи вводят руками - это всегда бардак.
...
Рейтинг: 0 / 0
09.09.2020, 12:48
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39997019
Сотрудник Главного Управления
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сотрудник Главного Управления
Участник
zeon11
наши ФИО

zeon11
-оглы, -кызы

Золотая Орда?
...
Рейтинг: 0 / 0
09.09.2020, 18:25
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39997038
Фотография Валерий Юринский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валерий Юринский
Участник
GrigoriyFomin
Доброго дня. Подскажите академическое красивое решение именования таблиц и их полей при проектировании базы.
Есть справочник клиентов CLIENTS, ключевое поле CLID, есть справочник льгот BENS, ключевое поле BNID и есть таблица со связью клиента и льгот. Как красиво ее назвать (таких троек таблиц будет много по разным сущностям), и как понятно назвать связывающую таблицу и ее поля (пара клиента и льготы)?

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

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

По мере работы выявятся несовершенства, которые вы исправите.
...
Рейтинг: 0 / 0
09.09.2020, 19:14
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39997042
Фотография Валерий Юринский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валерий Юринский
Участник
egorych
softwarer
В-четвёртых, таблицу связи, если она понадобится, назвать client_privilege.
и как тогда назвать первичный ключ у этой таблицы? client_privilege_id? как то заковыристо, на мой вкус

Первичный ключ у этой таблицы может быть составным.
Код: plsql
1.
2.
CONSTRAINT client_privilege#p
   PRIMARY KEY(client_id, privilege_id)
...
Рейтинг: 0 / 0
09.09.2020, 19:19
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39997044
Фотография Валерий Юринский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валерий Юринский
Участник
Dimkas
crutchmaster,
именно потребность в автоматизации построения запросов и породила решение

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

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

Приведите, пожалуйста, пример, чтобы публика оценила.
...
Рейтинг: 0 / 0
09.09.2020, 19:21
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39997048
Фотография Валерий Юринский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валерий Юринский
Участник
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
Валерий Юринский
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
>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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ВМоисеев
А если так:
1. справочник клиентов - tbl_Client

Не раньше, чем Вас начнут звать чел_ВМоисеев.
...
Рейтинг: 0 / 0
11.09.2020, 13:34
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39997633
Alibek B
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alibek B
Участник
У префиксов есть одно удобство — с ними можно не думать о конфликтах с системными именами и зарезервированными словами. Называть таблицы T_USER, например.
...
Рейтинг: 0 / 0
11.09.2020, 13:45
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39997660
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
>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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
Alibek B.
У префиксов есть одно удобство — с ними можно не думать о конфликтах с системными именами и зарезервированными словами. Называть таблицы T_USER, например.
Можно и без них не думать о конфликтах, используя стандартные способы экранирования, которые есть практически в любой "нормальной" СУБД. Обычно для этого используются кавычки вокруг имён объектов, т.е., вместо User можно писать "User" и никаких конфликтов. В MS SQL такую же роль могут играть квадратные скобки, например [User]. А учитывая, что объекты легко распределить между схемами, тоже весьма распространённым механизмом, то смысл в префиксах и вовсе отпадает. Не говоря уж о том, что системные объекты и так уже нередко имеют наименование с префиксом.

Некоторые и вовсе городят префиксы, описывающими тип объекта, что-то вроде tbl_AnyName или vue_AnyName, что говорит лишь о неудобстве интерфейса, в котором они работают. Вменяемые средства, как правило, позволяют легко отделить "овнов" от "козлищ" и без таких натужных способов. А в запросе всё равно, что таблица, что представление, всё равно все обращения к таковым объектам в большинстве случаев меняются на "говорящие" псевдонимы(алиасы).
...
Рейтинг: 0 / 0
11.09.2020, 17:11
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39997744
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ВМоисеев
префикс может идентифицировать не только таблицу, но и представление (view), построенном на базе таблицы
особенное удовольствие от такого стандарта кодирования получаешь, когда в процессе жизненного цикла базы таблица превращается в представление, или наоборот :)
...
Рейтинг: 0 / 0
11.09.2020, 18:01
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39997862
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Валерий Юринский
Код: 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
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
>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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ennor Tiegael
Участник
ChA
Alibek B.
У префиксов есть одно удобство — с ними можно не думать о конфликтах с системными именами и зарезервированными словами. Называть таблицы T_USER, например.
Можно и без них не думать о конфликтах, используя стандартные способы экранирования, которые есть практически в любой "нормальной" СУБД. Обычно для этого используются кавычки вокруг имён объектов, т.е., вместо User можно писать "User" и никаких конфликтов. В MS SQL такую же роль могут играть квадратные скобки, например [User]. А учитывая, что объекты легко распределить между схемами, тоже весьма распространённым механизмом, то смысл в префиксах и вовсе отпадает. Не говоря уж о том, что системные объекты и так уже нередко имеют наименование с префиксом.

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

Я как-то писал вьюхи, экспортирующие данные из системы, где одна из ключевых таблиц называлась dbo.Case - мало не показалось.
...
Рейтинг: 0 / 0
12.09.2020, 21:07
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39997986
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критик
Участник
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ennor Tiegael
Участник
ВМоисеев
>hVostt, вчера, 23:38 https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1328925&msg=22195703][22195703]
>...а вы ещё тип данных батенька в имя поля засуньте, чтоб вообще смешно было :))...
<
Почему смешно?
Потому, что когда придется поменять тип столбца, придется его и переименовывать заодно. После чего ловить блох по всей БД (и всем клиентским приложениям, работающим с этой базой), если используемые тулзы не умеют делать нормальный Rename / Find All References.
...
Рейтинг: 0 / 0
12.09.2020, 21:11
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39997990
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
>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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
Ennor Tiegael
Обычно проблемой бывает конфликт не с системными объектами (в MSSQL они в отдельной схеме), а с reserved keywords. Таблицы User, Group, Order - это трэш при кодировании, постоянно квадратные скобки добавлять приходится. Мне проще переводить их в множественное число, всего +1 доп. символ, и тот обычно покрывается Intellisense'ом.

Я как-то писал вьюхи, экспортирующие данные из системы, где одна из ключевых таблиц называлась dbo.Case - мало не показалось.
На мой взгляд, хорошим тоном при написании запросов считается обязательное указание схемы объекта, что обычно снимает проблему с "опасными" наименованиями. Как минимум, это полезно для того, чтобы engine точно знал из какой схемы брать объект, а не подбирал по своему алгоритму. Схема фактически определяет пространство имён. С наименованием полей, в принципе, та же ситуация, только роль схемы тут играет имя таблицы(псевдоним). Без их точного указания есть немалый шанс, что поле будет выбрано тоже "случайно", а вовсе не то, которое подразумевал программист при написании запроса.
...
Рейтинг: 0 / 0
13.09.2020, 00:07
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39998008
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ChA
На мой взгляд, хорошим тоном при написании запросов считается обязательное указание схемы объекта, что обычно снимает проблему с "опасными" наименованиями.

Не думаю, что указание схемы решит проблему с зарезервированными словами. Хотя, конечно, зависит от синтаксического анализатора. Что касается хорошего тона - думаю, это хороший тон для приложений, размещённых в нескольких схемах. Когда же оно занимает одну схему - практика как минимум спорная, особенно в проектах для внешнего заказчика.
...
Рейтинг: 0 / 0
13.09.2020, 00:22
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #39998015
Андрей Юниор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Юниор
Участник
Как мне кажется, всё довольно просто.

Отвечая на исходный вопрос темы, у нас принято добавлять слово "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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ennor Tiegael
Участник
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alibek B
Участник
Андрей Юниор
Мне не нужно читать блок FROM, чтобы понять, что происходит в SELECT и WHERE - я могу сразу читать только нужную часть запроса. Мне не нужно запоминать алиасы.

EAV.
Да и без EAV бывает несколько соединений с одной и той же таблицей.
...
Рейтинг: 0 / 0
13.09.2020, 09:04
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40000686
Фотография Валерий Юринский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валерий Юринский
Участник
egorych
ВМоисеев
префикс может идентифицировать не только таблицу, но и представление (view), построенном на базе таблицы
особенное удовольствие от такого стандарта кодирования получаешь, когда в процессе жизненного цикла базы таблица превращается в представление, или наоборот :)

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

Как уже сегодня заметили: сегодня это таблица, а завтра view.
Editioned view напрямую выполняют функции таблиц.
...
Рейтинг: 0 / 0
20.09.2020, 21:00
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40000687
Фотография Валерий Юринский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валерий Юринский
Участник
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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimkas
Гость
Валерий Юринский

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

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

В целом к трёхбуквенным сокращениям привыкаешь очень сильно,
они быстро начинают восприниматься как просто термин - все вот эти PRC, PRS, SPR, MNT и т.д. - они ж как родные уже :))
...
Рейтинг: 0 / 0
21.09.2020, 11:26
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40000817
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Dimkas
В целом к трёхбуквенным сокращениям привыкаешь очень сильно,
они быстро начинают восприниматься как просто термин - все вот эти PRC, PRS, SPR, MNT и т.д. - они ж как родные уже :))


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

Люди сами создают себе проблемы, привыкают к этому и навязывают своё чувство приобретённого комфорта другим.

Имел "удовольствие" работать с SAP R/3, с ограничением 4-5 символов в названии. Лютый треш, особо доставляли таблички с названием типа ANAL.
...
Рейтинг: 0 / 0
21.09.2020, 11:46
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40000825
Фотография Валерий Юринский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валерий Юринский
Участник
Dimkas
Валерий Юринский

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

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

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

На 8i (1999 г.) ресурсов уже было намного больше, чем на Oracle v4, v5, где экономия была неизбежна :-)

И вас с "трехбуквенностью", прямо, как у дворника из "12 стульев" :-)
"12 стульев" by Ильф и ПетровВ пятницу 15 апреля 1927 года Ипполит Матвеевич, как обычно, проснулся в половине восьмого
и сразу же просунул нос в старомодное пенсне с золотой дужкой. Очков он не носил.
Однажды, решив, что носить пенсне негигиенично, Ипполит Матвеевич направился к оптику
и купил очки без оправы, с позолоченными оглоблями. Очки с первого раза ему понравились,
но жена (это было незадолго до ее смерти) нашла, что в очках он вылитый Милюков, и он отдал очки дворнику.
Дворник, хотя и не был близорук, к очкам привык и носил их с удовольствием.

:-)
...
Рейтинг: 0 / 0
21.09.2020, 11:53
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40000837
istrebitel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
istrebitel
Гость
hVostt

Имел "удовольствие" работать с SAP R/3, с ограничением 4-5 символов в названии. Лютый треш, особо доставляли таблички с названием типа ANAL.

 
Бооооль
Код: plsql
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.
257.
258.
259.
260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
271.
272.
273.
274.
275.
276.
277.
278.
279.
280.
281.
282.
283.
284.
285.
286.
287.
288.
289.
290.
291.
292.
293.
294.
295.
296.
297.
298.
299.
300.
301.
302.
303.
304.
305.
306.
307.
CREATE TABLE sl_load_out_mseg
    (bukrs                          VARCHAR2(4 BYTE),
    mblnr                          VARCHAR2(10 BYTE),
    mjahr                          NUMBER(4,0),
    zeile                          NUMBER(4,0),
    matnr                          VARCHAR2(18 BYTE),
    werks                          VARCHAR2(4 BYTE),
    lgort                          VARCHAR2(4 BYTE),
    charg                          VARCHAR2(10 BYTE),
    lifnr                          VARCHAR2(10 BYTE),
    waers                          VARCHAR2(5 BYTE),
    dmbtr                          NUMBER(13,2),
    bwart                          VARCHAR2(3 BYTE),
    menge                          NUMBER(13,3),
    meins                          VARCHAR2(3 BYTE),
    ebeln                          VARCHAR2(10 BYTE),
    ebelp                          NUMBER(5,0),
    sjahr                          NUMBER(4,0),
    smbln                          VARCHAR2(10 BYTE),
    smblp                          NUMBER(4,0),
    bklas                          VARCHAR2(4 BYTE),
    vmtr                           VARCHAR2(5 BYTE),
    vid_d                          VARCHAR2(1 BYTE),
    obj_num                        NUMBER(8,0),
    mwskz                          VARCHAR2(2 BYTE),
    bwtar                          VARCHAR2(10 BYTE),
    price                          NUMBER(13,2),
    manager                        VARCHAR2(5 BYTE),
    depcod                         VARCHAR2(6 BYTE),
    waers_buh                      VARCHAR2(5 BYTE),
    dmbtr_buh                      NUMBER(13,2),
    price_buh                      NUMBER(13,2),
    vopr                           VARCHAR2(4 BYTE),
    prz_hran                       VARCHAR2(1 BYTE),
    shkzg                          VARCHAR2(1 BYTE),
    error                          VARCHAR2(1 BYTE),
    deliv_st                       VARCHAR2(3 BYTE),
    werks_in                       VARCHAR2(4 BYTE),
    lgort_in                       VARCHAR2(4 BYTE),
    charg_in                       VARCHAR2(10 BYTE),
    bwart_in                       VARCHAR2(3 BYTE),
    xauto                          VARCHAR2(1 BYTE),
    line_id                        NUMBER(6,0),
    sgtxt                          VARCHAR2(50 BYTE),
    bklas_in                       VARCHAR2(4 BYTE),
    vid_d_in                       VARCHAR2(1 BYTE),
    cena                           NUMBER(13,2),
    lbkum                          NUMBER(13,3),
    salk3                          NUMBER(13,2),
    posnv                          NUMBER(6,0),
    wempf                          VARCHAR2(12 BYTE),
    kunnr                          VARCHAR2(10 BYTE),
    xblnr                          VARCHAR2(16 BYTE),
    vgbel                          VARCHAR2(10 BYTE),
    vgpos                          NUMBER(6,0),
    parent_id                      NUMBER(6,0),
    spez_od                        VARCHAR2(1 BYTE),
    lgort_ox                       VARCHAR2(4 BYTE),
    bstkd                          VARCHAR2(35 BYTE),
    mol                            VARCHAR2(3 BYTE),
    mol_name                       VARCHAR2(200 BYTE),
    umwrk                          VARCHAR2(4 BYTE),
    mol_in                         VARCHAR2(4 BYTE),
    price_rl                       NUMBER(13,2),
    error_iseg                     VARCHAR2(1 BYTE),
    iblnr                          VARCHAR2(10 BYTE),
    gjahr                          NUMBER(4,0),
    zeili                          NUMBER(3,0),
    xblni                          VARCHAR2(16 BYTE),
    invnu                          VARCHAR2(16 BYTE),
    zmcha_str_p                    VARCHAR2(30 BYTE),
    zmcha_vl                       VARCHAR2(30 BYTE),
    kunnr1                         VARCHAR2(10 BYTE),
    wempf1                         VARCHAR2(12 BYTE),
    bwtar_in                       VARCHAR2(10 BYTE),
    menge_alt                      NUMBER(13,3),
    meins_alt                      VARCHAR2(3 BYTE),
    empst_lgort                    VARCHAR2(25 BYTE),
    knote_out                      VARCHAR2(10 BYTE),
    z_charact                      VARCHAR2(264 BYTE),
    parnr                          NUMBER(10,0),
    znpo_td                        VARCHAR2(30 BYTE),
    posid                          VARCHAR2(24 BYTE),
    docnum                         VARCHAR2(10 BYTE),
    posnum                         NUMBER(6,0),
    country                        VARCHAR2(3 BYTE),
    npo_td                         VARCHAR2(25 BYTE),
    ztxt_prim                      VARCHAR2(264 BYTE),
    zmcha_prmtr                    VARCHAR2(18 BYTE),
    zmcha_prcharg                  VARCHAR2(10 BYTE),
    bzirk                          VARCHAR2(6 BYTE),
    netpr_zi                       NUMBER(11,2),
    waers_zi                       VARCHAR2(5 BYTE),
    mfrgr                          VARCHAR2(8 BYTE),
    brgew                          NUMBER(13,3),
    weight_shtuk_length            VARCHAR2(60 BYTE),
    ficha                          VARCHAR2(10 BYTE),
    whcha                          VARCHAR2(10 BYTE),
    id_query                       VARCHAR2(10 CHAR),
    posid_out                      VARCHAR2(24 BYTE))
  SEGMENT CREATION IMMEDIATE
  NOPARALLEL
  LOGGING
  MONITORING
/


-- Comments for SL_LOAD_OUT_MSEG

COMMENT ON COLUMN sl_load_out_mseg.bklas IS 'Класс оценки'
/
COMMENT ON COLUMN sl_load_out_mseg.bklas_in IS 'Класс оценки'
/
COMMENT ON COLUMN sl_load_out_mseg.brgew IS 'Вес брутто'
/
COMMENT ON COLUMN sl_load_out_mseg.bstkd IS 'Номер заказа клиента на поставку'
/
COMMENT ON COLUMN sl_load_out_mseg.bukrs IS 'Балансовая единица'
/
COMMENT ON COLUMN sl_load_out_mseg.bwart IS 'Вид движения материала(Управление запсами)'
/
COMMENT ON COLUMN sl_load_out_mseg.bwart_in IS 'Вид движения материала(Управление запсами)'
/
COMMENT ON COLUMN sl_load_out_mseg.bwtar IS 'Вид оценки'
/
COMMENT ON COLUMN sl_load_out_mseg.bwtar_in IS 'Вид оценки'
/
COMMENT ON COLUMN sl_load_out_mseg.bzirk IS 'Группа месторождений'
/
COMMENT ON COLUMN sl_load_out_mseg.cena IS 'Стоимость общего оцененного запаса до проводки'
/
COMMENT ON COLUMN sl_load_out_mseg.charg IS 'Номер партии'
/
COMMENT ON COLUMN sl_load_out_mseg.charg_in IS 'Номер партии'
/
COMMENT ON COLUMN sl_load_out_mseg.country IS 'Код страны'
/
COMMENT ON COLUMN sl_load_out_mseg.deliv_st IS 'Трехзначное текстовое поле для IDOC'
/
COMMENT ON COLUMN sl_load_out_mseg.depcod IS 'Код подразделения'
/
COMMENT ON COLUMN sl_load_out_mseg.dmbtr IS 'Сумма во внутренней валюте'
/
COMMENT ON COLUMN sl_load_out_mseg.dmbtr_buh IS 'Сумма во внетренней валюте'
/
COMMENT ON COLUMN sl_load_out_mseg.docnum IS 'Следующий документ'
/
COMMENT ON COLUMN sl_load_out_mseg.ebeln IS 'Номер заказа на поставку'
/
COMMENT ON COLUMN sl_load_out_mseg.ebelp IS 'Номер позиции документа закупки'
/
COMMENT ON COLUMN sl_load_out_mseg.empst_lgort IS 'Пункт приемки'
/
COMMENT ON COLUMN sl_load_out_mseg.error IS 'Поле текста (1 знак)'
/
COMMENT ON COLUMN sl_load_out_mseg.error_iseg IS 'Поле текста (1 знак)'
/
COMMENT ON COLUMN sl_load_out_mseg.ficha IS 'Первичная партия поступления'
/
COMMENT ON COLUMN sl_load_out_mseg.gjahr IS 'Финансовый год'
/
COMMENT ON COLUMN sl_load_out_mseg.iblnr IS 'Документ инвентаризации'
/
COMMENT ON COLUMN sl_load_out_mseg.id_query IS 'Идентификатор запроса функции'
/
COMMENT ON COLUMN sl_load_out_mseg.invnu IS 'Номер инвентаризации'
/
COMMENT ON COLUMN sl_load_out_mseg.knote_out IS 'Транспортный узел'
/
COMMENT ON COLUMN sl_load_out_mseg.kunnr IS 'Заказчик'
/
COMMENT ON COLUMN sl_load_out_mseg.kunnr1 IS 'Номер дебетора'
/
COMMENT ON COLUMN sl_load_out_mseg.lbkum IS 'Общий объем оцененного запаса'
/
COMMENT ON COLUMN sl_load_out_mseg.lgort IS 'Склад'
/
COMMENT ON COLUMN sl_load_out_mseg.lgort_in IS 'Склад'
/
COMMENT ON COLUMN sl_load_out_mseg.lgort_ox IS 'Склад'
/
COMMENT ON COLUMN sl_load_out_mseg.lifnr IS 'Номер счета поставщика'
/
COMMENT ON COLUMN sl_load_out_mseg.line_id IS 'Однозначный идентификатор строки документа'
/
COMMENT ON COLUMN sl_load_out_mseg.manager IS 'Менеджер'
/
COMMENT ON COLUMN sl_load_out_mseg.matnr IS 'Номер материала'
/
COMMENT ON COLUMN sl_load_out_mseg.mblnr IS 'Номер документа материала'
/
COMMENT ON COLUMN sl_load_out_mseg.meins IS 'Базисная единица измерения'
/
COMMENT ON COLUMN sl_load_out_mseg.meins_alt IS 'Единица измерения ввода'
/
COMMENT ON COLUMN sl_load_out_mseg.menge IS 'Количество'
/
COMMENT ON COLUMN sl_load_out_mseg.menge_alt IS 'Количество в ЕИ ввода'
/
COMMENT ON COLUMN sl_load_out_mseg.mfrgr IS 'Группа фрахта материала'
/
COMMENT ON COLUMN sl_load_out_mseg.mjahr IS 'Год документа материала'
/
COMMENT ON COLUMN sl_load_out_mseg.mol IS 'Группа сбыта'
/
COMMENT ON COLUMN sl_load_out_mseg.mol_in IS 'Склад'
/
COMMENT ON COLUMN sl_load_out_mseg.mol_name IS 'Поле текста, длина 200'
/
COMMENT ON COLUMN sl_load_out_mseg.mwskz IS 'Код налога на добавленную стоимость'
/
COMMENT ON COLUMN sl_load_out_mseg.netpr_zi IS 'Цена нетто'
/
COMMENT ON COLUMN sl_load_out_mseg.npo_td IS 'ГТД(ВТД)'
/
COMMENT ON COLUMN sl_load_out_mseg.obj_num IS 'Объект капстроя (на базе СПП-элемента)'
/
COMMENT ON COLUMN sl_load_out_mseg.parent_id IS 'Однозначный идентификатор строки документа'
/
COMMENT ON COLUMN sl_load_out_mseg.parnr IS 'Номер контактного лица'
/
COMMENT ON COLUMN sl_load_out_mseg.posid IS 'Элемент структурного плана проекта (СПП-элемент)'
/
COMMENT ON COLUMN sl_load_out_mseg.posid_out IS 'Элемент структурного плана проекта (СПП-элемент) (Откуда)'
/
COMMENT ON COLUMN sl_load_out_mseg.posnum IS 'Позиция следующего документа'
/
COMMENT ON COLUMN sl_load_out_mseg.posnv IS 'Предыдущая позиция документа сбыта'
/
COMMENT ON COLUMN sl_load_out_mseg.price IS 'Сумма во внутренний валюте'
/
COMMENT ON COLUMN sl_load_out_mseg.price_buh IS 'Сумма во внутренней валюте'
/
COMMENT ON COLUMN sl_load_out_mseg.price_rl IS 'Сумма во внутренней валюте'
/
COMMENT ON COLUMN sl_load_out_mseg.prz_hran IS 'Поле текста (1 знак)'
/
COMMENT ON COLUMN sl_load_out_mseg.salk3 IS 'Стоимость общего оцененного запаса до проводки'
/
COMMENT ON COLUMN sl_load_out_mseg.sgtxt IS 'Текст позиции'
/
COMMENT ON COLUMN sl_load_out_mseg.shkzg IS 'Индекатор дебета/кредита'
/
COMMENT ON COLUMN sl_load_out_mseg.sjahr IS 'Год документа материала'
/
COMMENT ON COLUMN sl_load_out_mseg.smbln IS 'Номер документа материала'
/
COMMENT ON COLUMN sl_load_out_mseg.smblp IS 'Позиция документа материала'
/
COMMENT ON COLUMN sl_load_out_mseg.spez_od IS 'Индикатор одной позиции'
/
COMMENT ON COLUMN sl_load_out_mseg.umwrk IS 'Завод-получатель/завод поставщик'
/
COMMENT ON COLUMN sl_load_out_mseg.vgbel IS 'Номер документа-образца'
/
COMMENT ON COLUMN sl_load_out_mseg.vgpos IS 'Номер образца позиции сделки'
/
COMMENT ON COLUMN sl_load_out_mseg.vid_d IS 'Код вида деятельности (хран)'
/
COMMENT ON COLUMN sl_load_out_mseg.vid_d_in IS 'Код вида деятельности (хран)'
/
COMMENT ON COLUMN sl_load_out_mseg.vmtr IS 'Вид материала в БИТ'
/
COMMENT ON COLUMN sl_load_out_mseg.vopr IS 'Код операции для интерфейса SAP->БИТ'
/
COMMENT ON COLUMN sl_load_out_mseg.waers IS 'Код валюты'
/
COMMENT ON COLUMN sl_load_out_mseg.waers_buh IS 'Код валюты'
/
COMMENT ON COLUMN sl_load_out_mseg.waers_zi IS 'Код валюты'
/
COMMENT ON COLUMN sl_load_out_mseg.weight_shtuk_length IS 'WEIGHT_SHTUK_LENGTH'
/
COMMENT ON COLUMN sl_load_out_mseg.wempf IS 'Получатель материала'
/
COMMENT ON COLUMN sl_load_out_mseg.wempf1 IS 'Получатель материала'
/
COMMENT ON COLUMN sl_load_out_mseg.werks IS 'Завод'
/
COMMENT ON COLUMN sl_load_out_mseg.werks_in IS 'Завод'
/
COMMENT ON COLUMN sl_load_out_mseg.whcha IS 'Партия ПС'
/
COMMENT ON COLUMN sl_load_out_mseg.xauto IS 'Индикатор: позиция создана автоматически'
/
COMMENT ON COLUMN sl_load_out_mseg.xblni IS 'Ссылочный номер инвентаризации'
/
COMMENT ON COLUMN sl_load_out_mseg.xblnr IS 'Ссылочный номер документа'
/
COMMENT ON COLUMN sl_load_out_mseg.z_charact IS 'Сертификаты'
/
COMMENT ON COLUMN sl_load_out_mseg.zeile IS 'Позиция документа материала'
/
COMMENT ON COLUMN sl_load_out_mseg.zeili IS 'Номер строки'
/
COMMENT ON COLUMN sl_load_out_mseg.zmcha_prcharg IS 'Исходная партия'
/
COMMENT ON COLUMN sl_load_out_mseg.zmcha_prmtr IS 'Исходный МТР'
/
COMMENT ON COLUMN sl_load_out_mseg.zmcha_str_p IS 'Short text'
/
COMMENT ON COLUMN sl_load_out_mseg.zmcha_vl IS 'Short text'
/
COMMENT ON COLUMN sl_load_out_mseg.znpo_td IS 'Значение признака'
/
COMMENT ON COLUMN sl_load_out_mseg.ztxt_prim IS 'Текст продажы материала'
/

...
Рейтинг: 0 / 0
21.09.2020, 12:14
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40001002
Фотография Валерий Юринский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валерий Юринский
Участник
istrebitel
hVostt

Имел "удовольствие" работать с SAP R/3, с ограничением 4-5 символов в названии. Лютый треш, особо доставляли таблички с названием типа ANAL.

 
Бооооль
Код: plsql
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.
257.
258.
259.
260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
271.
272.
273.
274.
275.
276.
277.
278.
279.
280.
281.
282.
283.
284.
285.
286.
287.
288.
289.
290.
291.
292.
293.
294.
295.
296.
297.
298.
299.
300.
301.
302.
303.
304.
305.
306.
307.
CREATE TABLE sl_load_out_mseg
    (bukrs                          VARCHAR2(4 BYTE),
    mblnr                          VARCHAR2(10 BYTE),
    mjahr                          NUMBER(4,0),
    zeile                          NUMBER(4,0),
    matnr                          VARCHAR2(18 BYTE),
    werks                          VARCHAR2(4 BYTE),
    lgort                          VARCHAR2(4 BYTE),
    charg                          VARCHAR2(10 BYTE),
    lifnr                          VARCHAR2(10 BYTE),
    waers                          VARCHAR2(5 BYTE),
    dmbtr                          NUMBER(13,2),
    bwart                          VARCHAR2(3 BYTE),
    menge                          NUMBER(13,3),
    meins                          VARCHAR2(3 BYTE),
    ebeln                          VARCHAR2(10 BYTE),
    ebelp                          NUMBER(5,0),
    sjahr                          NUMBER(4,0),
    smbln                          VARCHAR2(10 BYTE),
    smblp                          NUMBER(4,0),
    bklas                          VARCHAR2(4 BYTE),
    vmtr                           VARCHAR2(5 BYTE),
    vid_d                          VARCHAR2(1 BYTE),
    obj_num                        NUMBER(8,0),
    mwskz                          VARCHAR2(2 BYTE),
    bwtar                          VARCHAR2(10 BYTE),
    price                          NUMBER(13,2),
    manager                        VARCHAR2(5 BYTE),
    depcod                         VARCHAR2(6 BYTE),
    waers_buh                      VARCHAR2(5 BYTE),
    dmbtr_buh                      NUMBER(13,2),
    price_buh                      NUMBER(13,2),
    vopr                           VARCHAR2(4 BYTE),
    prz_hran                       VARCHAR2(1 BYTE),
    shkzg                          VARCHAR2(1 BYTE),
    error                          VARCHAR2(1 BYTE),
    deliv_st                       VARCHAR2(3 BYTE),
    werks_in                       VARCHAR2(4 BYTE),
    lgort_in                       VARCHAR2(4 BYTE),
    charg_in                       VARCHAR2(10 BYTE),
    bwart_in                       VARCHAR2(3 BYTE),
    xauto                          VARCHAR2(1 BYTE),
    line_id                        NUMBER(6,0),
    sgtxt                          VARCHAR2(50 BYTE),
    bklas_in                       VARCHAR2(4 BYTE),
    vid_d_in                       VARCHAR2(1 BYTE),
    cena                           NUMBER(13,2),
    lbkum                          NUMBER(13,3),
    salk3                          NUMBER(13,2),
    posnv                          NUMBER(6,0),
    wempf                          VARCHAR2(12 BYTE),
    kunnr                          VARCHAR2(10 BYTE),
    xblnr                          VARCHAR2(16 BYTE),
    vgbel                          VARCHAR2(10 BYTE),
    vgpos                          NUMBER(6,0),
    parent_id                      NUMBER(6,0),
    spez_od                        VARCHAR2(1 BYTE),
    lgort_ox                       VARCHAR2(4 BYTE),
    bstkd                          VARCHAR2(35 BYTE),
    mol                            VARCHAR2(3 BYTE),
    mol_name                       VARCHAR2(200 BYTE),
    umwrk                          VARCHAR2(4 BYTE),
    mol_in                         VARCHAR2(4 BYTE),
    price_rl                       NUMBER(13,2),
    error_iseg                     VARCHAR2(1 BYTE),
    iblnr                          VARCHAR2(10 BYTE),
    gjahr                          NUMBER(4,0),
    zeili                          NUMBER(3,0),
    xblni                          VARCHAR2(16 BYTE),
    invnu                          VARCHAR2(16 BYTE),
    zmcha_str_p                    VARCHAR2(30 BYTE),
    zmcha_vl                       VARCHAR2(30 BYTE),
    kunnr1                         VARCHAR2(10 BYTE),
    wempf1                         VARCHAR2(12 BYTE),
    bwtar_in                       VARCHAR2(10 BYTE),
    menge_alt                      NUMBER(13,3),
    meins_alt                      VARCHAR2(3 BYTE),
    empst_lgort                    VARCHAR2(25 BYTE),
    knote_out                      VARCHAR2(10 BYTE),
    z_charact                      VARCHAR2(264 BYTE),
    parnr                          NUMBER(10,0),
    znpo_td                        VARCHAR2(30 BYTE),
    posid                          VARCHAR2(24 BYTE),
    docnum                         VARCHAR2(10 BYTE),
    posnum                         NUMBER(6,0),
    country                        VARCHAR2(3 BYTE),
    npo_td                         VARCHAR2(25 BYTE),
    ztxt_prim                      VARCHAR2(264 BYTE),
    zmcha_prmtr                    VARCHAR2(18 BYTE),
    zmcha_prcharg                  VARCHAR2(10 BYTE),
    bzirk                          VARCHAR2(6 BYTE),
    netpr_zi                       NUMBER(11,2),
    waers_zi                       VARCHAR2(5 BYTE),
    mfrgr                          VARCHAR2(8 BYTE),
    brgew                          NUMBER(13,3),
    weight_shtuk_length            VARCHAR2(60 BYTE),
    ficha                          VARCHAR2(10 BYTE),
    whcha                          VARCHAR2(10 BYTE),
    id_query                       VARCHAR2(10 CHAR),
    posid_out                      VARCHAR2(24 BYTE))
  SEGMENT CREATION IMMEDIATE
  NOPARALLEL
  LOGGING
  MONITORING
/


-- Comments for SL_LOAD_OUT_MSEG

COMMENT ON COLUMN sl_load_out_mseg.bklas IS 'Класс оценки'
/
COMMENT ON COLUMN sl_load_out_mseg.bklas_in IS 'Класс оценки'
/
COMMENT ON COLUMN sl_load_out_mseg.brgew IS 'Вес брутто'
/
COMMENT ON COLUMN sl_load_out_mseg.bstkd IS 'Номер заказа клиента на поставку'
/
COMMENT ON COLUMN sl_load_out_mseg.bukrs IS 'Балансовая единица'
/
COMMENT ON COLUMN sl_load_out_mseg.bwart IS 'Вид движения материала(Управление запсами)'
/
COMMENT ON COLUMN sl_load_out_mseg.bwart_in IS 'Вид движения материала(Управление запсами)'
/
COMMENT ON COLUMN sl_load_out_mseg.bwtar IS 'Вид оценки'
/
COMMENT ON COLUMN sl_load_out_mseg.bwtar_in IS 'Вид оценки'
/
COMMENT ON COLUMN sl_load_out_mseg.bzirk IS 'Группа месторождений'
/
COMMENT ON COLUMN sl_load_out_mseg.cena IS 'Стоимость общего оцененного запаса до проводки'
/
COMMENT ON COLUMN sl_load_out_mseg.charg IS 'Номер партии'
/
COMMENT ON COLUMN sl_load_out_mseg.charg_in IS 'Номер партии'
/
COMMENT ON COLUMN sl_load_out_mseg.country IS 'Код страны'
/
COMMENT ON COLUMN sl_load_out_mseg.deliv_st IS 'Трехзначное текстовое поле для IDOC'
/
COMMENT ON COLUMN sl_load_out_mseg.depcod IS 'Код подразделения'
/
COMMENT ON COLUMN sl_load_out_mseg.dmbtr IS 'Сумма во внутренней валюте'
/
COMMENT ON COLUMN sl_load_out_mseg.dmbtr_buh IS 'Сумма во внетренней валюте'
/
COMMENT ON COLUMN sl_load_out_mseg.docnum IS 'Следующий документ'
/
COMMENT ON COLUMN sl_load_out_mseg.ebeln IS 'Номер заказа на поставку'
/
COMMENT ON COLUMN sl_load_out_mseg.ebelp IS 'Номер позиции документа закупки'
/
COMMENT ON COLUMN sl_load_out_mseg.empst_lgort IS 'Пункт приемки'
/
COMMENT ON COLUMN sl_load_out_mseg.error IS 'Поле текста (1 знак)'
/
COMMENT ON COLUMN sl_load_out_mseg.error_iseg IS 'Поле текста (1 знак)'
/
COMMENT ON COLUMN sl_load_out_mseg.ficha IS 'Первичная партия поступления'
/
COMMENT ON COLUMN sl_load_out_mseg.gjahr IS 'Финансовый год'
/
COMMENT ON COLUMN sl_load_out_mseg.iblnr IS 'Документ инвентаризации'
/
COMMENT ON COLUMN sl_load_out_mseg.id_query IS 'Идентификатор запроса функции'
/
COMMENT ON COLUMN sl_load_out_mseg.invnu IS 'Номер инвентаризации'
/
COMMENT ON COLUMN sl_load_out_mseg.knote_out IS 'Транспортный узел'
/
COMMENT ON COLUMN sl_load_out_mseg.kunnr IS 'Заказчик'
/
COMMENT ON COLUMN sl_load_out_mseg.kunnr1 IS 'Номер дебетора'
/
COMMENT ON COLUMN sl_load_out_mseg.lbkum IS 'Общий объем оцененного запаса'
/
COMMENT ON COLUMN sl_load_out_mseg.lgort IS 'Склад'
/
COMMENT ON COLUMN sl_load_out_mseg.lgort_in IS 'Склад'
/
COMMENT ON COLUMN sl_load_out_mseg.lgort_ox IS 'Склад'
/
COMMENT ON COLUMN sl_load_out_mseg.lifnr IS 'Номер счета поставщика'
/
COMMENT ON COLUMN sl_load_out_mseg.line_id IS 'Однозначный идентификатор строки документа'
/
COMMENT ON COLUMN sl_load_out_mseg.manager IS 'Менеджер'
/
COMMENT ON COLUMN sl_load_out_mseg.matnr IS 'Номер материала'
/
COMMENT ON COLUMN sl_load_out_mseg.mblnr IS 'Номер документа материала'
/
COMMENT ON COLUMN sl_load_out_mseg.meins IS 'Базисная единица измерения'
/
COMMENT ON COLUMN sl_load_out_mseg.meins_alt IS 'Единица измерения ввода'
/
COMMENT ON COLUMN sl_load_out_mseg.menge IS 'Количество'
/
COMMENT ON COLUMN sl_load_out_mseg.menge_alt IS 'Количество в ЕИ ввода'
/
COMMENT ON COLUMN sl_load_out_mseg.mfrgr IS 'Группа фрахта материала'
/
COMMENT ON COLUMN sl_load_out_mseg.mjahr IS 'Год документа материала'
/
COMMENT ON COLUMN sl_load_out_mseg.mol IS 'Группа сбыта'
/
COMMENT ON COLUMN sl_load_out_mseg.mol_in IS 'Склад'
/
COMMENT ON COLUMN sl_load_out_mseg.mol_name IS 'Поле текста, длина 200'
/
COMMENT ON COLUMN sl_load_out_mseg.mwskz IS 'Код налога на добавленную стоимость'
/
COMMENT ON COLUMN sl_load_out_mseg.netpr_zi IS 'Цена нетто'
/
COMMENT ON COLUMN sl_load_out_mseg.npo_td IS 'ГТД(ВТД)'
/
COMMENT ON COLUMN sl_load_out_mseg.obj_num IS 'Объект капстроя (на базе СПП-элемента)'
/
COMMENT ON COLUMN sl_load_out_mseg.parent_id IS 'Однозначный идентификатор строки документа'
/
COMMENT ON COLUMN sl_load_out_mseg.parnr IS 'Номер контактного лица'
/
COMMENT ON COLUMN sl_load_out_mseg.posid IS 'Элемент структурного плана проекта (СПП-элемент)'
/
COMMENT ON COLUMN sl_load_out_mseg.posid_out IS 'Элемент структурного плана проекта (СПП-элемент) (Откуда)'
/
COMMENT ON COLUMN sl_load_out_mseg.posnum IS 'Позиция следующего документа'
/
COMMENT ON COLUMN sl_load_out_mseg.posnv IS 'Предыдущая позиция документа сбыта'
/
COMMENT ON COLUMN sl_load_out_mseg.price IS 'Сумма во внутренний валюте'
/
COMMENT ON COLUMN sl_load_out_mseg.price_buh IS 'Сумма во внутренней валюте'
/
COMMENT ON COLUMN sl_load_out_mseg.price_rl IS 'Сумма во внутренней валюте'
/
COMMENT ON COLUMN sl_load_out_mseg.prz_hran IS 'Поле текста (1 знак)'
/
COMMENT ON COLUMN sl_load_out_mseg.salk3 IS 'Стоимость общего оцененного запаса до проводки'
/
COMMENT ON COLUMN sl_load_out_mseg.sgtxt IS 'Текст позиции'
/
COMMENT ON COLUMN sl_load_out_mseg.shkzg IS 'Индекатор дебета/кредита'
/
COMMENT ON COLUMN sl_load_out_mseg.sjahr IS 'Год документа материала'
/
COMMENT ON COLUMN sl_load_out_mseg.smbln IS 'Номер документа материала'
/
COMMENT ON COLUMN sl_load_out_mseg.smblp IS 'Позиция документа материала'
/
COMMENT ON COLUMN sl_load_out_mseg.spez_od IS 'Индикатор одной позиции'
/
COMMENT ON COLUMN sl_load_out_mseg.umwrk IS 'Завод-получатель/завод поставщик'
/
COMMENT ON COLUMN sl_load_out_mseg.vgbel IS 'Номер документа-образца'
/
COMMENT ON COLUMN sl_load_out_mseg.vgpos IS 'Номер образца позиции сделки'
/
COMMENT ON COLUMN sl_load_out_mseg.vid_d IS 'Код вида деятельности (хран)'
/
COMMENT ON COLUMN sl_load_out_mseg.vid_d_in IS 'Код вида деятельности (хран)'
/
COMMENT ON COLUMN sl_load_out_mseg.vmtr IS 'Вид материала в БИТ'
/
COMMENT ON COLUMN sl_load_out_mseg.vopr IS 'Код операции для интерфейса SAP->БИТ'
/
COMMENT ON COLUMN sl_load_out_mseg.waers IS 'Код валюты'
/
COMMENT ON COLUMN sl_load_out_mseg.waers_buh IS 'Код валюты'
/
COMMENT ON COLUMN sl_load_out_mseg.waers_zi IS 'Код валюты'
/
COMMENT ON COLUMN sl_load_out_mseg.weight_shtuk_length IS 'WEIGHT_SHTUK_LENGTH'
/
COMMENT ON COLUMN sl_load_out_mseg.wempf IS 'Получатель материала'
/
COMMENT ON COLUMN sl_load_out_mseg.wempf1 IS 'Получатель материала'
/
COMMENT ON COLUMN sl_load_out_mseg.werks IS 'Завод'
/
COMMENT ON COLUMN sl_load_out_mseg.werks_in IS 'Завод'
/
COMMENT ON COLUMN sl_load_out_mseg.whcha IS 'Партия ПС'
/
COMMENT ON COLUMN sl_load_out_mseg.xauto IS 'Индикатор: позиция создана автоматически'
/
COMMENT ON COLUMN sl_load_out_mseg.xblni IS 'Ссылочный номер инвентаризации'
/
COMMENT ON COLUMN sl_load_out_mseg.xblnr IS 'Ссылочный номер документа'
/
COMMENT ON COLUMN sl_load_out_mseg.z_charact IS 'Сертификаты'
/
COMMENT ON COLUMN sl_load_out_mseg.zeile IS 'Позиция документа материала'
/
COMMENT ON COLUMN sl_load_out_mseg.zeili IS 'Номер строки'
/
COMMENT ON COLUMN sl_load_out_mseg.zmcha_prcharg IS 'Исходная партия'
/
COMMENT ON COLUMN sl_load_out_mseg.zmcha_prmtr IS 'Исходный МТР'
/
COMMENT ON COLUMN sl_load_out_mseg.zmcha_str_p IS 'Short text'
/
COMMENT ON COLUMN sl_load_out_mseg.zmcha_vl IS 'Short text'
/
COMMENT ON COLUMN sl_load_out_mseg.znpo_td IS 'Значение признака'
/
COMMENT ON COLUMN sl_load_out_mseg.ztxt_prim IS 'Текст продажы материала'
/


Всё точно, как у нас!
Только не смесь французского с нижегородским,
а смесь английского с нижнесаксонским :-)

Комментарии к таблице - это уже русская доработка,
если судить по обилию грамматических ошибок, опечаток, неточностей и недоделок.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
COMMENT ON COLUMN bwart IS 'Вид движения материала(Управление запсами)'
COMMENT ON COLUMN bwart_in IS 'Вид движения материала(Управление запсами)'
COMMENT ON COLUMN dmbtr_buh IS 'Сумма во внетренней валюте'
COMMENT ON COLUMN kunnr1 IS 'Номер дебетора'
COMMENT ON COLUMN obj_num IS 'Объект капстроя (на базе СПП-элемента)'
COMMENT ON COLUMN shkzg IS 'Индекатор дебета/кредита'
COMMENT ON COLUMN vid_d IS 'Код вида деятельности (хран)'
COMMENT ON COLUMN vid_d_in IS 'Код вида деятельности (хран)'
COMMENT ON COLUMN weight_shtuk_length IS 'WEIGHT_SHTUK_LENGTH'
COMMENT ON COLUMN zmcha_str_p IS 'Short text'
COMMENT ON COLUMN zmcha_vl IS 'Short text'
COMMENT ON COLUMN ztxt_prim IS 'Текст продажы материала'


Вот это сильная вещь:
Код: sql
1.
2.
...COLUMN zeile IS 'Позиция документа материала'
...COLUMN zeili IS 'Номер строки'

Точно кто-нибудь перепутает!

Это
Код: plaintext
    weight_shtuk_length            VARCHAR2(60 BYTE),
напомнило встретившееся когда-то
Код: plaintext
WHEN_BYLO DATE
:-)
...
Рейтинг: 0 / 0
21.09.2020, 15:55
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40001458
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
Dimkas
Валерий Юринский

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

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

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


Кто ясно мыслит, тот ясно излагает. (А. Шопенгауэр)
Пересмотрел достаточно много баз данных различных МИСов - если вижу такие названия, то всё, туши свет! не база, а помойка,
у разработчиков каша в голове, зато апломба до небес!
Если у вас двадцать таблиц в БД, то да, ещё можно их хоть как-то закодировать в трёхбуквенные названия, а если в БД триста-четыреста таблиц (а нормальная МИС столько и содержит), то придумать столько коротких названий нереально.
...
Рейтинг: 0 / 0
22.09.2020, 19:56
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40001837
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
zeon11
то придумать столько коротких названий нереально.

Реально, допустим, всё. Я, например, участвовал в разработке одной нехилой системы (порядка сотни мегабайт собственных исходников на Си), в которой по техническим причинам имена функций были ограничены 8 символами.
...
Рейтинг: 0 / 0
23.09.2020, 18:38
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40001947
Dimkas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimkas
Гость
zeon11
Если у вас двадцать таблиц в БД, то да, ещё можно их хоть как-то закодировать в трёхбуквенные названия, а если в БД триста-четыреста таблиц (а нормальная МИС столько и содержит), то придумать столько коротких названий нереально.

В той базе, про которую шла речь, на сегодня более 400 таблиц и примерно половина активно используется.
Краткие названия (3-4 символа) даны только основным таблицам. Эти же названия являются групповыми префиксами.
Производные таблицы (связи, оглавления, журналы и т.д.) имеют более длинные составные имена.

Логику составления длинных имен я кратко описывал выше 22195168
...
Рейтинг: 0 / 0
24.09.2020, 07:31
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002200
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
Dimkas
.........

Логику составления длинных имен я кратко описывал выше 22195168


Вот я и говорю, туши свет!
1. Раз есть таблица МО (Медицинские организации), то в этой БД есть и таблица "Страховые организации", таблица "Контрагенты" и прочее. Получается, что на каждый тип организации создается своя таблица.
2. Поля BGDATE, CLDATE (даты введения и прекращения действия). Это хорошая идея, только что вы будете делать, когда выяснится, что медицинская организация временно прекращала несколько раз свою деятельность? Что, будете создавать новую запись для фактически той-же организации? Или придётся перекраивать структуру БД?
3. Поля BGREASON, CLREASON (основание введения в действие, основание прекращения действия) -
Поля текстовые, иначе в названиях полей был-бы префикс "ID". Т.е. в эти поля кто ни попадя "льет" всякую шнягу,
хотя оснований для начала-прекращения не так много, и вполне их можно оформить в отдельную таблицу, её хотя-бы можно было расширять.
4. Поле CRDATE - дата создания. Это вообще о чём? Дата создания записи? Или дата начала функционирования Медицинской организации? Если первое, то где время, а если второе, то зачем поле BGDATE?
5. Поля MDDATE (дата последнего изменения), MDREASON (основание последнего изменения) - они зачем? Всё-же логируется в таблицу MO_LOG.
6. "при загрузке данных используется промежуточная таблица MO_BUF". Я правильно понимаю, что простым запросом данные не получить, и чтобы пользователю представить актуальные данные необходимо все данные предварительно загрузить в барабан стиральной машинки?
7. В БД есть таблица "Supplier -> SPR", иначе, поставщик. Что будете делать, когда выяснится, что больница решит оказывать услуги сторонним организациям, например, проводить медицинские осмотры для всех автоколонн города? Создавать ещё кучу таблиц, только с логикой "Покупатель-потребитель"?
...
Рейтинг: 0 / 0
24.09.2020, 16:09
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002242
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
zeon11
6. "при загрузке данных используется промежуточная таблица MO_BUF". Я правильно понимаю, что простым запросом данные не получить, и чтобы пользователю представить актуальные данные необходимо все данные предварительно загрузить в барабан стиральной машинки?


Хорошая аналогия
...
Рейтинг: 0 / 0
24.09.2020, 17:01
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002311
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
zeon11
5. Поля MDDATE (дата последнего изменения), MDREASON (основание последнего изменения) - они зачем? Всё-же логируется в таблицу MO_LOG.

Не занимайтесь пожалуйста проектированием БД.
...
Рейтинг: 0 / 0
24.09.2020, 19:14
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002388
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
graycode
zeon11
5. Поля MDDATE (дата последнего изменения), MDREASON (основание последнего изменения) - они зачем? Всё-же логируется в таблицу MO_LOG.

Не занимайтесь пожалуйста проектированием БД.


graycode, это не мой велосипед, будьте внимательны в мелочах
...
Рейтинг: 0 / 0
25.09.2020, 06:31
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002442
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
zeon11,

они зачем? Всё-же логируется в таблицу ..._LOG.
Если это не ваш велосипед то извините, а ежели ваш, то таких "проектировщиков" лучше держать от проектирования подальше.
...
Рейтинг: 0 / 0
25.09.2020, 10:41
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002563
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
graycode
zeon11,

они зачем? Всё-же логируется в таблицу ... _LOG .

Если это не ваш велосипед то извините, а ежели ваш, то таких "проектировщиков" лучше держать от проектирования подальше.

А, теперь понял. Вы огнепламенный борец против "читателей из LOGa".
Теперь по порядку.
Если пройдёте по ссылке https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&msg=22195168,
то увидите, что там есть поле MDDATE - дата последнего изменения , не знаю зачем, но многие разработчики на изменяемые данные делают такое поле. Т.е. изменили данные - сделали пометку. Снова изменили - сделали новую пометку. и т.д. Надо отдать должное, эти разработчики по всей видимости сделали таблицу изменений, назвали её MO_LOG. Так вот, моя мысль заключалась в следующем: если уж разработчикам понадобилась информация о дате последнего изменения, то по правилам нормализации негоже хранить одну и туже информацию в двух местах - поле MDDATE изменяемой таблицы и в отдельной таблице MO_LOG. От чего-то надо отказываться. По мне, в этих условиях (ещё раз - этот велосипед не мой) , так лучше отказаться от поля MDDATE, и прочитать при необходимости всю информацию из таблицы MO_LOG, т.к. она наверняка более информативна. Ну а как эта таблица называется, дело десятое, хоть _LOG, хоть _IZMENENIJA, не я эти таблицы придумываю, но знаю одно, это такие-же таблицы и при необходимости их можно читать. И кстати, как правило эти таблицы не доступны шаловливым ручкам конечных пользователей, а следовательно именно в этих таблицах достоверная информация.
P.S. По поводу "проектировщиков".
При проектировании своих баз данных стремлюсь к тому, чтобы пользователю были недоступны возможности удалить запись или её изменить. Иными словами, пользователь думает, что он удалил запись или её изменил, на самом деле я "подсовываю" ему новую запись. Таким образом у меня вообще нет таблиц LOG и соответственно я таблицы LOG, как и вы, никогда не читаю.
...
Рейтинг: 0 / 0
25.09.2020, 15:06
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002624
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
zeon11
Так вот, моя мысль заключалась в следующем: если уж разработчикам понадобилась информация о дате последнего изменения, то по правилам нормализации негоже хранить одну и туже информацию в двух местах - поле MDDATE изменяемой таблицы и в отдельной таблице MO_LOG.

В таблице в OLTP системах хранится текущее актуальное состояние объекта и дата последнего изменения это именно текущее актуальное состояние объекта, в таблице лога хранится движение объекта во времени, доставать его тяжело и больно, если для работы системы нужны даты прохождения определенных состояний, то размещать их нужно именно в основной таблице, лог используется для разбора полетов или редко запускаемых отчетов, но никак не для оперативной работы, если вы любите стрелять себе в ногу, дело ваше, жаль что разгребать это после вас придется другим людям.
...
Рейтинг: 0 / 0
25.09.2020, 17:42
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002628
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Поля "дата последнего изменения" и "автор последнего изменения" с точки зрения бизнес-логики никогда и ни зачем не нужны. По крайней мере, очень трудно вспомнить случай, где они реально понадобились бы. Но у них есть одно ценное свойство - по ним удобно искать. Говорит Вася "я позавчера работал с этим договором" - и Пете этого, как правило, достаточно. Поэтому по цена/качество их нередко стоит поддерживать, не связываясь ради этого с громоздкими дополнительными структурами.
...
Рейтинг: 0 / 0
25.09.2020, 17:49
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002635
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
zeon11
1. Раз есть таблица МО (Медицинские организации) ...

Если это один из ключевых объектов системы, то почему нет, к чему такая категоричность?

zeon11
2. Поля BGDATE, CLDATE (даты введения и прекращения действия). Это хорошая идея, только что вы будете делать, когда выяснится, что медицинская организация временно прекращала несколько раз свою деятельность? Что, будете создавать новую запись для фактически той-же организации? Или придётся перекраивать структуру БД?

В основной таблице хранится текущее актуальное состояние объекта, а для сохранения цепочки периодов действия, на сколько я вижу, предлагается таблица _HIS, так что ничего перекраивать не нужно.

zeon11
3. Поля BGREASON, CLREASON (основание введения в действие, основание прекращения действия) -
Поля текстовые, иначе в названиях полей был-бы префикс "ID". Т.е. в эти поля кто ни попадя "льет" всякую шнягу,
хотя оснований для начала-прекращения не так много, и вполне их можно оформить в отдельную таблицу, её хотя-бы можно было расширять.

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

zeon11
4. Поле CRDATE - дата создания. Это вообще о чём? Дата создания записи? Или дата начала функционирования Медицинской организации? Если первое, то где время, а если второе, то зачем поле BGDATE?

В Oracle тип DATE содержит время.

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

Вы понимаете совершенно неправильно, что впрочем и неудивительно.

zeon11
7. В БД есть таблица "Supplier -> SPR", иначе, поставщик. Что будете делать, когда выяснится, что больница решит оказывать услуги сторонним организациям, например, проводить медицинские осмотры для всех автоколонн города? Создавать ещё кучу таблиц, только с логикой "Покупатель-потребитель"?

Вы себе не представляете, но в информационных системах бывают даже не таблицы, а целые отдельные модули SRM и CRM))
...
Рейтинг: 0 / 0
25.09.2020, 18:10
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002742
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
в таблице лога хранится движение объекта во времени, доставать его тяжело и больно


Я конечно дико извиняюсь, но если эти данные доставать тяжело и больно, нахрена они тогда такие упёрлись?

И какую пользу бизнес-логике приносит дата и время последнего изменения без знания о том, что конкретно менялось? Вот у вас таблица с 50 полями. Вы видите, что Вася автор последних изменений в такое-то время.

И чо?
...
Рейтинг: 0 / 0
26.09.2020, 00:11
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002743
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
если вы любите стрелять себе в ногу, дело ваше, жаль что разгребать это после вас придется другим людям


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

Зато вы себе ногу не отстрелите, хоть что-то хорошоее, да?
...
Рейтинг: 0 / 0
26.09.2020, 00:12
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002752
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
hVostt,

Да да да, а потом начинается разгребание вот таких вот каках 22203332 ...

Или биллинги начинают запускать массово, а там сплошняком группировки по максимальной дате по табличке логов весьма неслабых размеров, ой что же делать что же делать, можно как то соптимизировать запросы ... а еще бы логи почистить и оставить в оперативном доступе три последних месяца ... ))
...
Рейтинг: 0 / 0
26.09.2020, 01:35
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002882
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
graycode

Да да да, а потом начинается разгребание вот таких вот каках 22203332 ...


graycode, что за детский сад? Что вы сюда третьи топики притягиваете? Обиделись, что ваше "гениальное" высказывание
Когда оперативные данные нужно получать из лога, это отвратно спроектированная система
там проигнорировали? А что на него отвечать, это банальная истина, все её знают, что её обсуждать?
И наверняка уважаемый автор того топика это знает. Посмотрите его профиль, у него только в Оракле 1080 сообщений, он на форуме уже 15 лет, а сколько до этого пахал, никто кроме него не знает. И уж про то, что и откуда читать, думаю прекрасно разбирается. И ситуации бывают разные, и информационные системы достаются по наследству, и их надо сопровождать, а не рассуждать, правильно или нет спроектирована система. Поэтому вашу пошлость там проигнорировали.

А это что такое?
graycode

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


Это влажные мечты, как вы спасаете свой отдел? Все такие носятся от компьютера к компьютеру с факелами зажженными, не знают, что делать, причитают, плачут, руки заламывают, а тут появляетесь вы, весь в белом, золотой венок на голове, как же без него, и произносите: Когда оперативные данные нужно получать из лога, это отвратно спроектированная система
...
Рейтинг: 0 / 0
26.09.2020, 16:41
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002886
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
Да да да, а потом начинается разгребание вот таких вот каках 22203332 ...


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

А потом начинается, ООП говно, ФП говно, SOLID говно и т.д. от ребят, которые не осилили ни одной парадигмы из разработки.

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


Вариантов решения на сегодняшний момент -- масса.
Если кто-то не умеет, или не способен мыслить и решать задачи, это его проблемы.
...
Рейтинг: 0 / 0
26.09.2020, 16:51
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002930
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
zeon11
graycode, что за детский сад?

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

zeon11
Посмотрите его профиль, у него только в Оракле 1080 сообщений, он на форуме уже 15 лет, а сколько до этого пахал, никто кроме него не знает.

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

zeon11
Это влажные мечты

Ваши влажные мечты меня как то совсем не интересуют.


hVostt
Ни одна концепция сама по себе не является серебряной пулей.

Не могу не согласиться))

hVostt
А потом начинается, ООП говно, ФП говно, SOLID говно и т.д. от ребят, которые не осилили ни одной парадигмы из разработки.

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

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

Масса, да, но они не бесплатные и зачем устраивать себе в OLTP системе геморрой на ровном месте?
...
Рейтинг: 0 / 0
26.09.2020, 19:18
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002965
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
hVostt
А потом начинается, ООП говно, ФП говно, SOLID говно и т.д. от ребят, которые не осилили ни одной парадигмы из разработки.

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


К паттерну репозиторий у меня много претензий, но в основном не к самому паттерну, а к тому как его понимают и применяют. К SOLID, в целом тоже самое. Там где вы ратуете за SRP, вы сами же его жёстко нарушаете, но не понимаете этого. Понимание рано или поздно придёт, если вы не решите сменить область деятельности. Дискутировать вы не захотели, чтобы углубить понимание, решили, что у вас есть "мнение" и этого достаточно.

Любая команда будет рада человеку, который придёт со своим мнением, ведь мнение священно, оно у каждого своё и аргументировать его не нужно :)

graycode
hVostt
Вариантов решения на сегодняшний момент -- масса.
Если кто-то не умеет, или не способен мыслить и решать задачи, это его проблемы.

Масса, да, но они не бесплатные и зачем устраивать себе в OLTP системе геморрой на ровном месте?


Да нет никакого геморроя. Я так понимаю, это лично ваш горький опыт. Не думайте, что у всех так.
Мы никаких проблем не испытывали с огромным объёмом информации, количеством сущностей, связей и бизнес-логикой.
...
Рейтинг: 0 / 0
26.09.2020, 22:32
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002973
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
hVostt
К паттерну репозиторий у меня много претензий, но в основном не к самому паттерну, а к тому как его понимают и применяют. К SOLID, в целом тоже самое.

О том как правильно с вашей точки зрения применять вышеозначенные принципы мы узнаем?

hVostt
Там где вы ратуете за SRP, вы сами же его жёстко нарушаете, но не понимаете этого.

Мысли я читать не умею, а каким образом я нарушаю SRP вы рассказать не удосужились.

hVostt
Дискутировать вы не захотели, чтобы углубить понимание, решили, что у вас есть "мнение" и этого достаточно.

О чем дискутировать, если идут общие слова характеризующие мнение и не несущие конкретики, собственно обменялись мнениями и разошлись, каждый при своем мнении))

hVostt
Да нет никакого геморроя. Я так понимаю, это лично ваш горький опыт. Не думайте, что у всех так.
Мы никаких проблем не испытывали с огромным объёмом информации, количеством сущностей, связей и бизнес-логикой.

Снова общие слова, увы они не несут конкретики и не являются аргументацией.
...
Рейтинг: 0 / 0
27.09.2020, 00:09
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40002981
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
hVostt
К паттерну репозиторий у меня много претензий, но в основном не к самому паттерну, а к тому как его понимают и применяют. К SOLID, в целом тоже самое.

О том как правильно с вашей точки зрения применять вышеозначенные принципы мы узнаем?


Конечно, ведь об этом уже трепались в какой-то из тем.

graycode
hVostt
Там где вы ратуете за SRP, вы сами же его жёстко нарушаете, но не понимаете этого.

Мысли я читать не умею, а каким образом я нарушаю SRP вы рассказать не удосужились.


Так вы решили прекратить дискуссию в той теме.

graycode
hVosttДискутировать вы не захотели, чтобы углубить понимание, решили, что у вас есть "мнение" и этого достаточно.

О чем дискутировать, если идут общие слова характеризующие мнение и не несущие конкретики, собственно обменялись мнениями и разошлись, каждый при своем мнении))

Не, это вы ушли. Я-то остался :)
Честно говоря, мне непонятен термин "мнение" в контексте инженерной дисциплины.

Представьте себе, как два математика спорят, один считает, что 2+2=4, а другой считает, что 2+2=5. Понимаете дикий абсурд ситуации? В чём смысл подобного "обмена мнениями" в подобных случаях?

Я вот говорю, вы не правы в том топике. И мне как-то всё равно, останетесь вы при своём мнении, или нет. Нет цели вас в чём-то убедить.

graycode
hVostt
Да нет никакого геморроя. Я так понимаю, это лично ваш горький опыт. Не думайте, что у всех так.
Мы никаких проблем не испытывали с огромным объёмом информации, количеством сущностей, связей и бизнес-логикой.

Снова общие слова, увы они не несут конкретики и не являются аргументацией.


Погодите, это вы заикнулись:

graycode
В таблице в OLTP системах хранится текущее актуальное состояние объекта и дата последнего изменения это именно текущее актуальное состояние объекта, в таблице лога хранится движение объекта во времени, доставать его тяжело и больно


И я вам прямо говорю, что тяжело и больно -- исключительно для вас. Так как вы пока не умеете работать с такими данными, ещё не хватает опыта, чтобы сделать такую архитектуру и организацию, чтобы не было тяжело и больно.

Какие вам здесь аргументы нужны? Вы и дальше собираетесь настаивать, что такая задача "тяжело и больно" решается для всех?

Интересно, если вы столкнётесь с концепцией Event Sourcing, мозги взорвутся и разметаются по стенам? Ведь там вообще мастер-данные это поток событий -- изменений данных, никаких тебе таблиц.
...
Рейтинг: 0 / 0
27.09.2020, 01:26
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003046
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
hVostt
Конечно, ведь об этом уже трепались в какой-то из тем.

То что трепались это заметно ...

hVostt
Так вы решили прекратить дискуссию в той теме.

Если бы была дискуссия, но вы ее уводите в болтологию и кидание какашками, а это мне не интересно.

hVostt
Честно говоря, мне непонятен термин "мнение" в контексте инженерной дисциплины.

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

hVostt
Представьте себе, как два математика спорят, один считает, что 2+2=4, а другой считает, что 2+2=5. Понимаете дикий абсурд ситуации? В чём смысл подобного "обмена мнениями" в подобных случаях?

К чему этот абсурдный пример? Вы считаете, что 2+2=5? Ну да переубеждать вас не имеет смысла, поэтому и общение с вами было прекращено.

hVostt
Я вот говорю, вы не правы в том топике. И мне как-то всё равно, останетесь вы при своём мнении, или нет. Нет цели вас в чём-то убедить.

А я говорю, что вы не правы и мне тоже как-то все равно, останетесь вы при своём мнении, или нет, и у меня тоже нет цели вас в чем-то убедить.

hVostt
И я вам прямо говорю, что тяжело и больно -- исключительно для вас. Так как вы пока не умеете работать с такими данными, ещё не хватает опыта, чтобы сделать такую архитектуру и организацию, чтобы не было тяжело и больно.

Вы оказывается еще и Ванга, по хрустальному шару гадали кто что умеет или не умеет? Вот потому с вами и было прекращено общение, ибо конструктива никакого, конкретики никакой, а выслушивать от форумских троллей что я что то не умею или не хватает опыта, идите ка вы тролли в сад.

hVostt
Интересно, если вы столкнётесь с концепцией Event Sourcing, мозги взорвутся и разметаются по стенам? Ведь там вообще мастер-данные это поток событий -- изменений данных, никаких тебе таблиц.

И какой ответ вы хотите на этот высер? Можете не отвечать ...

PS: общение с вами дорогой мой неадекватный друг закончено.
...
Рейтинг: 0 / 0
27.09.2020, 13:28
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003169
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
Если бы была дискуссия, но вы ее уводите в болтологию и кидание какашками, а это мне не интересно.


Вам не интересно, когда у вас кончаются аргументы.
Вот это очевидно, а ваша характеристика дискуссии -- обыкновенная попытка съехать с темы, и не более того.


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


Но вот здесь, вы не предложили никакого способа.
Но заявили, что это "больно".
Причина — отсутствие у вас нужных компетенций.
Что нам с вашим мнением делать? Посочуствовать?

graycode
К чему этот абсурдный пример? Вы считаете, что 2+2=5? Ну да переубеждать вас не имеет смысла, поэтому и общение с вами было прекращено.


Пример у тому, что вы не готовы вести дискуссию, так как у вас нет аргументов.
Ваше нежелание вполне обосновано.
На нет и суда нет.

graycode
Вы оказывается еще и Ванга, по хрустальному шару гадали кто что умеет или не умеет? Вот потому с вами и было прекращено общение, ибо конструктива никакого, конкретики никакой, а выслушивать от форумских троллей что я что то не умею или не хватает опыта, идите ка вы тролли в сад.


Теперь вы сваливаетесь в унылое хамство. Это вполне ожидаемо от людей, не способных на конструктивную беседу.

graycode
PS: общение с вами дорогой мой неадекватный друг закончено.


Мда, печально, что вы оказались унылым хамлом.
...
Рейтинг: 0 / 0
28.09.2020, 01:27
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003170
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
hVostt
Мда, печально, что вы оказались унылым хамлом.

Увы, все что вы описали в своем пространном посте вы начали первым, собственно и получаете в ответ.

Вот вам конкретика, есть выборка записей из таблицы t по попаданию поля some_date в заданный интервал, вы утверждаете, что можете получить такой же результат в случае когда поле some_date находится в таблице t_log (лог для таблицы t), а в таблице t отсутствует, при этом стоить это будет не больше в любом разрезе, по ресурсам, по времени выполнения, по сложности поддержки и т.д.

Чтобы было еще больше конкретики, таблица t - 70 миллионов записей, таблица t_log - 700 миллионов записей.
запрос из t - (select * from t where some_date between d1 and d2), где d1 и d2 - параметры. В случае с таблицей t_log необходимо по максимальной дате some_date попадающей в интервал d1-d2 найти идентификаторы и по ним отобрать записи из таблицы t.

Продемонстрируйте свою компетенцию, докажите ваше утверждение.
...
Рейтинг: 0 / 0
28.09.2020, 02:04
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003171
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
вы утверждаете, что можете получить такой же результат


Зачем вы мне приписываете утверждения, которых я не делал?

graycode
Чтобы было еще больше конкретики, таблица t - 70 миллионов записей, таблица t_log - 700 миллионов записей.
запрос из t - (select * from t where some_date between d1 and d2), где d1 и d2 - параметры. В случае с таблицей t_log необходимо по максимальной дате some_date попадающей в интервал d1-d2 найти идентификаторы и по ним отобрать записи из таблицы t.


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

Ладно, пусть мне пока непонятно, что и зачем вы делаете, поэтому придётся придумать за вас.
Зачем-то бизнесу нужно получить записи, которые изменялись в последний раз в какой-то интервал времени.
Хрен знает зачем оно нужно бизнесу, от чего вам так "больно", но бог с ним.

Заводится таблица с датой последнего изменения сущности. И всё.
Это называется проекция изменений.
Даже если такая таблица понадобится потом, её легко наполнить из лога изменений.

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

Как будете решать? Страдать? :)

Я вот как буду делать, сделаю ещё одну проекцию. Хоть 100500 штук, да это увеличит объём базы, но всё будет работать максимально быстро. А когда проекция будет не нужна, дропну её.
...
Рейтинг: 0 / 0
28.09.2020, 02:25
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003172
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
hVostt,
Мусорный фон в ваших сообщениях мне не интересен, поэтому смотреть и отвечать буду только по конкретике.

hVostt
Заводится таблица с датой последнего изменения сущности. И всё.
Это называется проекция изменений.
Даже если такая таблица понадобится потом, её легко наполнить из лога изменений.

Т.е. вместо добавления поля в основную таблицу, вы предлагаете создать таблицу расширения 1:1 и получить дополнительное соединение в запросах и что самое главное, дополнительные затраты на поддержку этого расширения, и этот костыль вы предлагаете в контексте OLTP систем, я правильно понял?

hVostt
Я вот как буду делать, сделаю ещё одну проекцию. Хоть 100500 штук, да это увеличит объём базы, но всё будет работать максимально быстро. А когда проекция будет не нужна, дропну её.

Т.е. если вы захотите например иметь время изменения ключевых статусов объекта, пусть их будет 5 и отбирать объекты по этому времени, то вы вместо добавления 10 полей (статус, дата) создадите дополнительные 5 табличек (1:1) с двумя полями и во всех запросах по всему приложению добавите 5 соединений с этими дополнительными табличками, также будете поддерживать триггеры вставляющие и изменяющие записи в эти 5 табличек?
...
Рейтинг: 0 / 0
28.09.2020, 03:05
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003187
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
graycode
hVostt
Мда, печально, что вы оказались унылым хамлом.

Увы, все что вы описали в своем пространном посте вы начали первым, собственно и получаете в ответ.

Вот вам конкретика, есть выборка записей из таблицы t по попаданию поля some_date в заданный интервал, вы утверждаете, что можете получить такой же результат в случае когда поле some_date находится в таблице t_log (лог для таблицы t), а в таблице t отсутствует, при этом стоить это будет не больше в любом разрезе, по ресурсам, по времени выполнения, по сложности поддержки и т.д.

Чтобы было еще больше конкретики, таблица t - 70 миллионов записей, таблица t_log - 700 миллионов записей.
запрос из t - (select * from t where some_date between d1 and d2), где d1 и d2 - параметры. В случае с таблицей t_log необходимо по максимальной дате some_date попадающей в интервал d1-d2 найти идентификаторы и по ним отобрать записи из таблицы t.

Продемонстрируйте свою компетенцию, докажите ваше утверждение.


Какая-то каша. Давайте по порядку, без грубостей и ваших любимых советов не заниматься проектированием БД.
1. Таблица логов, как правило, создается для того, чтобы в перспективе поймать какого-нибудь менеджера Васю Пупкина на умышленных или непредумышленных действиях. Под Васей Пупкиным мы сейчас понимаем и группу лиц, и оборудование, и бизнес-процессы. Т.е. Взаимодействие с таблицей логов носит экстраординарный внеплановый характер.
2. Само по себе наличие таблицы логов противоречит правилам нормализации, поскольку данные фактически дублируются.
3. Наличие таблицы логов говорит о том, что разработчик системы не уверен в своей системе и допускает умышленное или непредумышленное искажение данных. Теперь ваш пример t - 70 миллионов записей, таблица t_log - 700 миллионов записей
Уверенны-ли вы в том, что все 70 миллионов записей достоверны, при том, что в среднем они 10 раз поменялись?
4. t_log - 700 миллионов записей, предположим, это данные за 5 лет, нехитрыми расчетами мы можем выяснить, что это 266 изменений записей в минуту. Какой смысл хранить данные о последнем изменившем запись, если через доли секунды эту запись надо будет обновлять? Зачем дёргать триггер-на-изменение на таблице t ? И да, самая хохма, что при такой логике, очень легко "положить" любую БД. Понятно, да, о чем я говорю? Вася Пупкин меняет контрагента, триггер меняет последнюю дату изменения на новую, это приводит к срабатыванию триггера и т.д.
6. По вашему запросу (select * from t where some_date between d1 and d2) , нам надо выбрать, кто последний наследил в этой записи. Ну, выясним из таблицы t, что это был менеджер Пупкин. Ну и что? всё равно нам надо узнать, что он поменял и на что. Всё равно надо ползти в таблицу t_Log.
Код: sql
1.
select L.* from t_Log L where L.ID_t=:ID_t order by L.ID_t_Log desc fetch FIRST 1 ROWS ONLY


Запрос как запрос, все поля индексированы, отработает моментально. Где тут "тяжело и больно"?

Ещё раз, повторюсь, надо исходить из конкретики задачи. И решения будут разные. Конкретно по этим условиям t - 70 миллионов записей, таблица t_log - 700 миллионов записей . Скорее всего БД спроектирована неудачно, это скорее биллинг, и тут вообще стоит запретить какие-либо изменения-удаления записей. Тупо добавляй изменённую запись как новую. Никаких триггеров, никаих логов тогда не надо.
...
Рейтинг: 0 / 0
28.09.2020, 07:10
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003200
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
graycode
........

Чтобы было еще больше конкретики, таблица t - 70 миллионов записей, таблица t_log - 700 миллионов записей.
запрос из t - (select * from t where some_date between d1 and d2), где d1 и d2 - параметры. В случае с таблицей t_log необходимо по максимальной дате some_date попадающей в интервал d1-d2 найти идентификаторы и по ним отобрать записи из таблицы t.


Давно в руки хрустальный шар не брал ;-)

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
 select T.* from t T
 where 1=1
   and exists (
         select L.* from t_Log L 
            where 1=1
           and L.ID_t=T.ID_t
           and L.some_date = (select LL.some_date from  t_Log LL
                                           where 1=1 
                                             and LL.some_date between :d1 and :d2 
                                           order by LL.ID_t_Log desc fetch FIRST 1 ROWS ONLY)
                    )



Это что-ли?
...
Рейтинг: 0 / 0
28.09.2020, 08:13
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003251
Фотография Валерий Юринский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валерий Юринский
Участник
zeon11
2. Само по себе наличие таблицы логов противоречит правилам нормализации, поскольку данные фактически дублируются.

Это вы что-то новое придумали!
Подумайте. :-)
...
Рейтинг: 0 / 0
28.09.2020, 11:08
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003296
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
hVostt,
Мусорный фон в ваших сообщениях мне не интересен, поэтому смотреть и отвечать буду только по конкретике.


Зачем вы опять начинаете хамить, я вообще не понимаю.

graycode
Т.е. вместо добавления поля в основную таблицу, вы предлагаете создать таблицу расширения 1:1 и получить дополнительное соединение в запросах и что самое главное, дополнительные затраты на поддержку этого расширения, и этот костыль вы предлагаете в контексте OLTP систем, я правильно понял?


Я историю для вас расширил, можете ответить, вы как будете решать?

По вашему вопросу. Бизнес хочет получать ответы на свои запросы быстро. Это всегда связано с какими-то затратами. То, что вы называете по вашей необразованности "костылём", в продуктовых системах называется "денормализация", и она есть практически везде.


graycode
Т.е. если вы захотите например иметь время изменения ключевых статусов объекта, пусть их будет 5 и отбирать объекты по этому времени, то вы вместо добавления 10 полей (статус, дата) создадите дополнительные 5 табличек (1:1) с двумя полями и во всех запросах по всему приложению добавите 5 соединений с этими дополнительными табличками, также будете поддерживать триггеры вставляющие и изменяющие записи в эти 5 табличек?


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

По поводу триггеров, вам так или иначе нужно триггерить изменения, чтобы писать либо в поля, либо в таблицу, разницы нет. В любом случае, я стараюсь избегать триггеров СУБД, и работать через поток событий. Практика показывает, что триггеры это УГ.
...
Рейтинг: 0 / 0
28.09.2020, 12:13
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003464
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
hVostt
Так как вы пока не умеете работать с такими данными, ещё не хватает опыта, чтобы сделать такую архитектуру и организацию, чтобы не было тяжело и больно.

Вы педалируете эту тему (что является ничем иным как переход на личности и начали хамить именно вы и продолжаете это делать, за что получаете в ответ) уже много сообщений подряд и вот наконец то я увидел конкретику, и оказалось, что такие говнокостыли которые вы предлагаете я уже делал и делал их когда в основную таблицу добавлять поля по тем или иным причинам было запрещено. Т.е. ваш подход для меня совсем не нов и в разрезе oltp это лютый трэш, для oltp это равносильно 2*2=5. Если вы это делаете в аналитической системе, то это совершенно другой вопрос, но в oltp это антипаттерн.

Вкратце минусы такого подхода: на операции DML на основной таблице мы вынуждены делать дополнительные операции по поддержке таблиц расширений; на таблицах расширений должен быть как минимум один индекс на id, т.е. 20 таблиц расширений, двадцать индексов, что очень "положительно" сказывается на производительности вставки записей; когда мы получаем данные, мы вынуждены присоединять таблицы расширений, что очень "положительно" сказывается на производительности запросов, если понадобился составной индекс из полей основной таблицы и поля из дополнения ... ; поиск по полям принадлежащим нескольким таким таблицам тоже очень "положительно" сказывается на производительности запросов. И имея такую кучу минусов утверждать, что это решение для oltp систем лучше чем добавление полей необходимых для оперативной работы в основную таблицу, это за гранью логики.

hVostt
в продуктовых системах называется "денормализация", и она есть практически везде.

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

hVostt
Практика показывает, что триггеры это УГ.

В общем и целом да, они дают дополнительные накладные расходы, если есть возможность реализовать ту же логику в приложении, то конечно это более хороший вариант.
...
Рейтинг: 0 / 0
28.09.2020, 15:25
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003518
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
zeon11
Какая-то каша. Давайте по порядку, без грубостей и ваших любимых советов не заниматься проектированием БД.
1. Таблица логов, как правило, создается для того, чтобы в перспективе поймать какого-нибудь менеджера Васю Пупкина на умышленных или непредумышленных действиях. Под Васей Пупкиным мы сейчас понимаем и группу лиц, и оборудование, и бизнес-процессы. Т.е. Взаимодействие с таблицей логов носит экстраординарный внеплановый характер.
2. Само по себе наличие таблицы логов противоречит правилам нормализации, поскольку данные фактически дублируются.
3. Наличие таблицы логов говорит о том, что разработчик системы не уверен в своей системе и допускает умышленное или непредумышленное искажение данных. Теперь ваш пример t - 70 миллионов записей, таблица t_log - 700 миллионов записей
Уверенны-ли вы в том, что все 70 миллионов записей достоверны, при том, что в среднем они 10 раз поменялись?
4. t_log - 700 миллионов записей, предположим, это данные за 5 лет, нехитрыми расчетами мы можем выяснить, что это 266 изменений записей в минуту. Какой смысл хранить данные о последнем изменившем запись, если через доли секунды эту запись надо будет обновлять? Зачем дёргать триггер-на-изменение на таблице t ? И да, самая хохма, что при такой логике, очень легко "положить" любую БД. Понятно, да, о чем я говорю? Вася Пупкин меняет контрагента, триггер меняет последнюю дату изменения на новую, это приводит к срабатыванию триггера и т.д.
6. По вашему запросу (select * from t where some_date between d1 and d2) , нам надо выбрать, кто последний наследил в этой записи. Ну, выясним из таблицы t, что это был менеджер Пупкин. Ну и что? всё равно нам надо узнать, что он поменял и на что. Всё равно надо ползти в таблицу t_Log.
Код: sql
1.
select L.* from t_Log L where L.ID_t=:ID_t order by L.ID_t_Log desc fetch FIRST 1 ROWS ONLY


Запрос как запрос, все поля индексированы, отработает моментально. Где тут "тяжело и больно"?

Ещё раз, повторюсь, надо исходить из конкретики задачи. И решения будут разные. Конкретно по этим условиям t - 70 миллионов записей, таблица t_log - 700 миллионов записей . Скорее всего БД спроектирована неудачно, это скорее биллинг, и тут вообще стоит запретить какие-либо изменения-удаления записей. Тупо добавляй изменённую запись как новую. Никаких триггеров, никаих логов тогда не надо.


1. Совершенно верно, таблица лога не должна использоваться для оперативной работы о чем я и говорил, но вы почему то с этим спорили, почему вы с этим спорили? Поменяли свое мнение?
2. Таблица логов решает свою задачу и она вполне себе нормализованная, дублирования данных в ней нет.
3. Таблица логов нужна для разбора полетов, если что то пошло не так. Естественно данные в таблице факта достоверны и актуальны, даже если кто то внес ошибочные данные, они являются фактом и именно на тот случай что кто то внес недостоверную информацию нужна таблица логов, чтобы посмотреть что кто и когда и принять решение о том как откорректировать факт.
4. 70 миллионов в факте, допустим каждый объект в среднем проходит 10 состояний, итого получаем 700 в логе, это вполне реальное соотношение и такой прирост за 5 лет это даже не сильно нагруженная система, а лог за прошлые годы можно банально заархивировать куда нибудь в сторонку и удалить из оперативной системы, разумеется если на нем кто то нехороший не построил логику оперативной работы. Факт -> лог дорога с односторонним движением, т.е. никаких цепочек она не порождает и никакую базу не положит.
6. Что касается запросов данных для максимальной даты попадающей в интервал то вот 13931438 и вот 8947782 как они выглядят. Но когда таблица лога начинает использоваться подобным образом для работы оперативной системы, это ведет к сильной просадке производительности, у нее другое предназначение и ходят за данными в нее обычно при проведении исследования кто и как нагадил, ходят по конкретному идентификатору объекта, т.е. в логи при нормальном раскладе обычно идут с конкретным идентификатором, а таких записей в нашем примере 70/700 там всего 10 штук.

Естественно, когда биллинг считают по таблице лога это трэш, а возникает он, когда проектировщик считает что если что то пишется в лог, то достанем оттуда и будет нам счастье.
zeon11
Вот я и говорю, туши свет! ...
5. Поля MDDATE (дата последнего изменения), MDREASON (основание последнего изменения) - они зачем? Всё-же логируется в таблицу MO_LOG.
Лежат себе поля, хлеба не просят, поддержка их стоит минимально, но иногда бывают весьма полезны, никакой видимой причины для хэйта нет, однако ...

"и тут вообще стоит запретить какие-либо изменения-удаления записей" - запрет изменения вы себе как представляете?
...
Рейтинг: 0 / 0
28.09.2020, 16:17
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003547
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
Вы педалируете эту тему (что является ничем иным как переход на личности и начали хамить именно вы и продолжаете это делать, за что получаете в ответ)


Нет не является. Успокойтесь пожалуйста и выдохните. Хватит уже этих соплей :)

graycode
я увидел конкретику, и оказалось, что такие говнокостыли которые вы предлагаете я уже делал и делал их когда в основную таблицу добавлять поля по тем или иным причинам было запрещено. Т.е. ваш подход для меня совсем не нов и в разрезе oltp это лютый трэш, для oltp это равносильно 2*2=5. Если вы это делаете в аналитической системе, то это совершенно другой вопрос, но в oltp это антипаттерн.


Можете пояснить почему это антипаттерн?
В чём проблемы? Откуда вообще вы это взяли?

graycode
Вкратце минусы такого подхода: на операции DML на основной таблице мы вынуждены делать дополнительные операции по поддержке таблиц расширений; на таблицах расширений должен быть как минимум один индекс на id, т.е. 20 таблиц расширений, двадцать индексов, что очень "положительно" сказывается на производительности вставки записей; когда мы получаем данные, мы вынуждены присоединять таблицы расширений, что очень "положительно" сказывается на производительности запросов, если понадобился составной индекс из полей основной таблицы и поля из дополнения ... ; поиск по полям принадлежащим нескольким таким таблицам тоже очень "положительно" сказывается на производительности запросов. И имея такую кучу минусов утверждать, что это решение для oltp систем лучше чем добавление полей необходимых для оперативной работы в основную таблицу, это за гранью логики.


Есть задачи и требования. Любая реализация требует определённых затрат. Они абсолютно оправданы, если выхлоп больше трудозатрат. Ничего бесплатного не бывает.

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

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

graycode
hVostt
в продуктовых системах называется "денормализация", и она есть практически везде.

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


Ну да, понятно, да...

А мне вот что интересно.
Вы в очередной раз игнорируете заданный мною вопрос.
Я ведь даже повторил его выше.

Это с чем связано? Если не знаете (что итак уже очевидно), так и скажите.
...
Рейтинг: 0 / 0
28.09.2020, 16:56
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003548
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
Лежат себе поля, хлеба не просят, поддержка их стоит минимально, но иногда бывают весьма полезны, никакой видимой причины для хэйта нет, однако ...


Вы даже объяснить не можете на кой хер они там лежат и какую задачу вы решаете :)
А чуть более усложнить задачу, так вы тупо игнорируете вопросы.

Конечно, я верю, что вы проектировщик от бога, раз указываете другим что им не стоит заниматься проектированием. С такими-то познаниями )))
...
Рейтинг: 0 / 0
28.09.2020, 16:57
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003565
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
hVostt
Явных значимых минусов из вашего описания я не заметил. Да, нужны доп. операции, да нужны индексы, на вставку записей это не влияет, так как заполнение проекций выполняется асинхронно. Влияния на нормализованную модель данных нет, и не нужно добавлять мусор в таблицы.

У вас логика проявляет все признаки отсутствия присутствия, вы не понимаете суть oltp систем в принципе, на сим не вижу смысла пытаться вам объяснять что дважды два четыре, это бесполезно в вашем случае и тратить на вас время бессмысленно, тем более что конкретики снова никакой, одни общие слова.
...
Рейтинг: 0 / 0
28.09.2020, 17:16
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003609
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
У вас логика проявляет все признаки отсутствия присутствия, вы не понимаете суть oltp систем в принципе, на сим не вижу смысла пытаться вам объяснять что дважды два четыре, это бесполезно в вашем случае и тратить на вас время бессмысленно, тем более что конкретики снова никакой, одни общие слова.


Описанное решение никак не противоречит принципам OLTP, а только дополняют их.
Вы этого опровергнуть не можете, и аргументировать не способны.

Но вы ясно дали нам понять, что задача для вас "больно и сложно".
Для меня, моей команды -- эта задача не проблема.

Ваши попытки свою неспособность решать задачи перенести на чужие плечи -- курам на смех.
Идити проектируйте дальше, горе-проектировщик
...
Рейтинг: 0 / 0
28.09.2020, 18:19
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003628
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
graycode

..........................
6. Что касается запросов данных для максимальной даты попадающей в интервал то вот 13931438 и вот 8947782 как они выглядят. Но когда таблица лога начинает использоваться подобным образом для работы оперативной системы, это ведет к .........


Не понял, что за шняга? Вы мне с апломбом несколько раз рекомендовали не заниматься проектированием баз данных, потом выкатили с вашей точки зрения супер-пупер сложную задачу с посылом "а ну-ка решите недоумки!". Я вам решил вашу супер-пупер задачу в один простецкий запрос, а вы мне тыкаете в нос запросы какого-то левого чувака, которые не относятся к вашей супер-пупер задаче совсем никак, типа поучись. Вы сами-то в тех запросах разобрались? Или быстро-быстро поиском по форуму пробежались, нашли старьё, что хоть-бы отдалённо было по теме и сюда выкатили?
Не, так дело не пойдёт.
Глядя на вас мне вспомнился сериал "Интерны" где Быков говорит Лобанову:
"У тебя есть шанс стать прекрасным врачом, а вот Левин считает себя мощным специалистом, и у него такого шанса нет"
...
Рейтинг: 0 / 0
28.09.2020, 18:56
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003633
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
graycode
Явных значимых минусов из вашего описания я не заметил. Да, нужны доп. операции, да нужны индексы, на вставку записей это не влияет, так как заполнение проекций выполняется асинхронно. Влияния на нормализованную модель данных нет, и не нужно добавлять мусор в таблицы.

Количество индексов не влияет на вставку записей? ну ну ...
Транзакционные данные асинхронно? Ну ну ...
Влияния на нормализованную модель данных нет? Я веду с вами беседу в контексте oltp систем, если нет влияния на оперативную работу и оперативные данные, то это рядом стоящая аналитическая система и каким боком это относится к контексту oltp?

Я вам про oltp, а вы мне говорите что прекрасно делаете срезы, витрины, проекции, процедуры загрузки в них (ETL), вот только при чем тут oltp?

hVostt
Идити проектируйте дальше, горе-проектировщик

И вам того же, топайте проектируйте дальше, горе-проектировщик
...
Рейтинг: 0 / 0
28.09.2020, 19:10
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003639
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
zeon11
Не понял, что за шняга? Вы мне с апломбом несколько раз рекомендовали не заниматься проектированием баз данных, потом выкатили с вашей точки зрения супер-пупер сложную задачу с посылом "а ну-ка решите недоумки!". Я вам решил вашу супер-пупер задачу в один простецкий запрос, а вы мне тыкаете в нос запросы какого-то левого чувака, которые не относятся к вашей супер-пупер задаче совсем никак, типа поучись. Вы сами-то в тех запросах разобрались? Или быстро-быстро поиском по форуму пробежались, нашли старьё, что хоть-бы отдалённо было по теме и сюда выкатили?

Это не левый чувак, это Добрый Э - Эх , а вот вы действительно левый чувак))

Далее, в который раз пытаюсь донести до вас простую истину, когда такие запросы используются в массовом порядке для того чтобы вытащить данные необходимые для оперативной работы из таблиц лога, это приводит к существенному замедлению работы системы, поскольку ресурсы и время на выполнение таких запросов растут в геометрической прогрессии при росте количества данных в системе.
...
Рейтинг: 0 / 0
28.09.2020, 19:20
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003640
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
Я вам про oltp


Похоже вы познакомились с одним единственным термином, и теперь у вас наступил OLTP головного мозга :)

Жаль, что это не помогает вам решать проблемы, от чёго от простейших задач у вас боль и страдание
...
Рейтинг: 0 / 0
28.09.2020, 19:29
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003642
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
С нами заслуженный олтп-гуру, вы ребят по-осторожнее с ним
...
Рейтинг: 0 / 0
28.09.2020, 19:30
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003643
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
hVostt
Похоже вы познакомились с одним единственным термином, и теперь у вас наступил OLTP головного мозга :)

Нет, просто вы стали оспаривать то, что поля необходимые для оперативной транзакционной работы системы должны находиться в основных таблицах, я не понял с чего вы так решили и как то адекватно аргументировать свою позицию вы не смогли, вместо этого вы устроили клоунаду.
...
Рейтинг: 0 / 0
28.09.2020, 19:37
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003644
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
Количество индексов не влияет на вставку записей? ну ну ...
Транзакционные данные асинхронно? Ну ну ...


Учитывая отсутствие у вас банальных знаний и самое главное опыта, вам остаётся только нунукать :)

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

Очевидно, всё что находится за рамками транзакции одной БД, для вас тёмный непроходимый лес.
Вы даже в OLTP умудрились боль и страдание найти

graycode
Я вам про oltp, а вы мне говорите что прекрасно делаете срезы, витрины, проекции, процедуры загрузки в них (ETL), вот только при чем тут oltp?


Ваша проблема в том, что вы делаете свой мифический OLTP, а я решаю задачи бизнеса.
Моя команда решает их быстро, эффективно и вполне успешно. При чём никаких принципов OLTP в таких системах не нарушается. ВЫ просто не хотите видеть ничего дальше носа.
...
Рейтинг: 0 / 0
28.09.2020, 19:37
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003645
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
hVostt
Похоже вы познакомились с одним единственным термином, и теперь у вас наступил OLTP головного мозга :)

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


Какую клоунаду? Вы не ответили на мой вопрос, находящийся в поле обозначенной вами проблемы.
Значит вы не знаете как решать задачу.

Хлопаете дверью.
Ноете и сопли развозите.

Ответить на вопрос можете или нет?
...
Рейтинг: 0 / 0
28.09.2020, 19:39
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003659
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
graycode
zeon11
Не понял, что за шняга? Вы мне с апломбом несколько раз рекомендовали не заниматься проектированием баз данных, потом выкатили с вашей точки зрения супер-пупер сложную задачу с посылом "а ну-ка решите недоумки!". Я вам решил вашу супер-пупер задачу в один простецкий запрос, а вы мне тыкаете в нос запросы какого-то левого чувака, которые не относятся к вашей супер-пупер задаче совсем никак, типа поучись. Вы сами-то в тех запросах разобрались? Или быстро-быстро поиском по форуму пробежались, нашли старьё, что хоть-бы отдалённо было по теме и сюда выкатили?

Это не левый чувак, это Добрый Э - Эх , а вот вы действительно левый чувак))

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


Ну и что же? Это губернатор острова Борнео? (С)
Что вы как попка-попугай повторяете одно и тоже? Я и без вас всегда знал, что из лога не стоит брать данные, но если надо, то их можно взять. И это совсем не больно, как вы утверждали тут. И с чего вы взяли, что это приводит к существенному замедлению работы системы, поскольку ресурсы и время на выполнение таких запросов растут в геометрической прогрессии при росте количества данных в системе ? Хотя в системах спроектированных вами, скорее всего именно так и происходит - и больно, и медленно.
Для вас Лог какой-то фетиш. Вас что, в детстве Логом напугали, что ходите тут по форуму, где увидите слово Лог, сразу какать начинаете? Успокойтесь-же наконец, Лог - это такая-же таблица, ни чем не отличается от других таблиц.

Всё, я спать пошел, у нас пол-перврго ночи.
...
Рейтинг: 0 / 0
28.09.2020, 20:21
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003666
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
zeon11
Я и без вас всегда знал, что из лога не стоит брать данные

Почему же вы тогда с пеной у рта спорили и утверждали обратное?))

Да и посмотрел на ваш запрос, он неправильный ... )) что же вы так, товарищ hVostt за вас вписался, а вы запросы писать не умеете)), все таки посмотрите ссылочки на то как правильно писать такие запросы))
...
Рейтинг: 0 / 0
28.09.2020, 20:34
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003732
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
graycode

.....
Вот вам конкретика, есть выборка записей из таблицы t по попаданию поля some_date в заданный интервал, вы утверждаете, что можете получить такой же результат в случае когда поле some_date находится в таблице t_log (лог для таблицы t), а в таблице t отсутствует, при этом стоить это будет не больше в любом разрезе, по ресурсам, по времени выполнения, по сложности поддержки и т.д.

Чтобы было еще больше конкретики, таблица t - 70 миллионов записей, таблица t_log - 700 миллионов записей.
запрос из t - (select * from t where some_date between d1 and d2), где d1 и d2 - параметры. В случае с таблицей t_log необходимо по максимальной дате some_date попадающей в интервал d1-d2 найти идентификаторы и по ним отобрать записи из таблицы t.

Продемонстрируйте свою компетенцию, докажите ваше утверждение.


Вот ваши условия:
В случае с таблицей t_log необходимо по максимальной дате some_date попадающей в интервал d1-d2 найти идентификаторы и по ним отобрать записи из таблицы t.
Вот мой ответ в 1 запрос:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
 
select T.* from t T
 where 1=1
   and exists (
         select L.* from t_Log L 
            where 1=1
           and L.ID_t=T.ID_t
           and L.some_date = (select LL.some_date from  t_Log LL
                                           where 1=1 
                                            and LL.some_date between :d1 and :d2 
                                           order by LL.ID_t_Log desc fetch FIRST 1 ROWS ONLY)
                    )



Как сформулировали, так и получили.

Есть вариант изменить запрос, более подходящий к контексту, но выходящий за пределы ваших условий:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
 
select T.* from t T
 where 1=1
   and exists (
         select L.* from t_Log L 
            where 1=1
           and L.ID_t=T.ID_t
           and L.some_date = (select LL.some_date from  t_Log LL
                                           where 1=1 
                                            and LL.ID_t=T.ID_t  //  добавил 
                                            and LL.some_date between :d1 and :d2 
                                           order by LL.ID_t_Log desc fetch FIRST 1 ROWS ONLY)
                    )



Итак, что в этих запросах вам не нравится? Давайте без воды, без общих фраз. Вот конкретные запросы. Естественно я их нигде не проверял, написал из общих соображений, и я не ораклист. Где, какая строчка неправильная? Я всегда учусь, мне самому интересно, где ошибка?
...
Рейтинг: 0 / 0
29.09.2020, 06:31
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40003978
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
zeon11
Итак, что в этих запросах вам не нравится?

Они не решают поставленную задачу.

zeon11
Вот конкретные запросы. Естественно я их нигде не проверял

Что же помешало благородному дону за которого вписался hVostt, проверить логику своего творения?

Если сами не справитесь, накидаю вам тестовый пример ...

zeon11
и я не ораклист

Почему в таком случае вы позволили себе написать неквалифицированный и необоснованный 22203605 хэйт ораклисту?

Могли бы написать на MS SQL, тем более что ссылки на примеры таких запросов я вам уже дал на обоих диалектах.

zeon11
Где, какая строчка неправильная?

Код: sql
1.
and LL.some_date between :d1 and :d2
...
Рейтинг: 0 / 0
29.09.2020, 14:17
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40004023
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
graycode

Почему в таком случае вы позволили себе написать неквалифицированный и необоснованный 22203605 хэйт ораклисту?

[/src]


А что там от оракла? Нормализация для всех одинакова, и для оракла, и для foxpro
...
Рейтинг: 0 / 0
29.09.2020, 15:17
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40004024
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
graycode

Код: sql
1.
and LL.some_date between :d1 and :d2



Что концептуально не правильно?
...
Рейтинг: 0 / 0
29.09.2020, 15:20
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40004044
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
[quot graycode#22206460]

И да, hVostt ни за кого не вписывался, он вполне аргументированно показал вашу профессиональную несостоятельность, может быть и достаточно импульсивно, но по сути всё было верно.
Вы дважды в последних постах ко мне упомянули, что hVostt "вписался" за меня, и это не может быть опечаткой, из чего я делаю вывод что он вас полностью жестоко "поломал", ваше эго, может быть подспудно ищет выход из сложившегося внутреннего дискомфорта, и ничего лучшего ваше подсознание не придумало, чем легенду, типа hVostt не со мной воевал, это он за zeona заступался. А вот я теперь zeona "поломаю", и как-бы одержу окончательную победу.
Я просмотрел ваши немногочисленные посты на этом форуме и по тому, как вы приклеиваете ярлыки совершенно незнакомым людям, уличая их якобы в некомпетентности, у меня сложилось о вас мнение как о глубоко закомплексованном человеке, не получившем реализации в жизни. Обратите внимание, здесь, на форуме в целом люди помогают друг другу профессионально расти. Помогают студентам, неофитам, и как правило оскорбления и советы заняться чем-нибудь другим, здесь на форуме вызывают ответную негативную реакцию.
На этом считаю наш диалог завершенным, свое мнение о вас как о человеке и профессионале у меня сформировалось. Если чем-то обидел, то извините.
...
Рейтинг: 0 / 0
29.09.2020, 16:06
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40004112
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
graycode
Гость
zeon11
Что концептуально не правильно?

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

вот вам тестовый пример:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
with t (ID_t, name) as
 (
              select 1, 'Первая строка' from dual
    union all select 2, 'Вторая строка' from dual
    union all select 3, 'Третья строка' from dual
 ),
 t_Log(ID_t_Log, ID_t, some_date) as
 (
              select 1001, 1, to_date('01.01.2010', 'DD.MM.YYYY') from dual
    union all select 1002, 1, to_date('10.09.2020', 'DD.MM.YYYY') from dual
    union all select 1003, 1, to_date('30.11.2020', 'DD.MM.YYYY') from dual
    union all select 1004, 2, to_date('01.01.2010', 'DD.MM.YYYY') from dual
    union all select 1005, 2, to_date('09.09.2020', 'DD.MM.YYYY') from dual
    union all select 1006, 2, to_date('10.09.2020', 'DD.MM.YYYY') from dual
    union all select 1007, 3, to_date('01.01.2010', 'DD.MM.YYYY') from dual
    union all select 1008, 3, to_date('09.09.2020', 'DD.MM.YYYY') from dual
    union all select 1009, 3, to_date('01.11.2020', 'DD.MM.YYYY') from dual
 )


Интервал дат:
Код: sql
1.
to_date('07.09.2020', 'DD.MM.YYYY') and to_date('11.09.2020', 'DD.MM.YYYY')




zeon11
И да, hVostt ни за кого не вписывался

Да нет, в неадекват он ушел из за вас, он же не думал что защищает такого кадра, хотя это было видно невооруженным взглядом.

zeon11
у меня сложилось о вас мнение как о глубоко закомплексованном человеке, не получившем реализации в жизни

Ваше мнение очень важно для нас
...
Рейтинг: 0 / 0
29.09.2020, 18:51
| Ответить | Цитировать | Написать  
подскажите хорошую практику наименования связанных таблиц
    #40004163
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
graycode
zeon11
Итак, что в этих запросах вам не нравится?

Они не решают поставленную задачу.


Напоминаю вам, что вы так и не озвучили, какую задачу решаете.
Теперь донимаете людей, как правильно ковыряться в носу.
...
Рейтинг: 0 / 0
30.09.2020, 00:15
| Ответить | Цитировать | Написать  
132 сообщений из 132, показаны все 6 страниц
  все  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / подскажите хорошую практику наименования связанных таблиц
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=32&tid=1539838]:
 0ms
get settings:
 11ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 31ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 210ms
get tp. blocked users:
 1ms
others: 240ms
total:  526ms
созд. / загр.: 526ms
x
x
Закрыть


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