ReSQL.ru
     
powered by simpleCommunicator - 2.0.48     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Категории или одна таблица
19 сообщений из 44, страница 2 из 2
  2  все
Категории или одна таблица
    #40034142
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
Serguei

Я никогда не утверждал, что существуют системы, которые никак не контролируют целостность данных.


Если считать "использование foreign key" и "контроль целостности" синонимами, как тогда понимать эту фразу?

Serguei
ptr128
softwarer,
есть ERP, которые не используют foreign key на уровне БД. Но тогда они используют foreign key на уровне сервера приложений.


Данное утверждение было бы верно ...


Вы уж либо приводите пример, где данное утверждение не верно, либо посыпайте голову пеплом )))
...
Рейтинг: 0 / 0
08.01.2021, 13:53
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40040753
Фотография Валерий Юринский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валерий Юринский
Участник
ptr128
L_argo,

больше всего не люблю такие таблицы из-за того, что во всех таблицах, которые на них ссылаются, приходится хранить не только ссылку на элемент справочник, но и код этого справочника (хотя бы в вычисляемом постоянном поле). Иначе foreign key не сделать.

Ну и что тут страшного? Код справочника много места не займёт.
На код справочника можно ещё жесткий CHECK "навесить".
В SELECTах его использовать не придётся:
Код: sql
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.
CREATE TABLE UNISPR(
   SPR_ID NUMBER(20) NOT NULL
 , SPR_KOD NUMBER(5) NOT NULL
 , SPR_NAME VARCHAR2(250) NOT NULL
 , CONSTRAINT UNISPR#P 
      PRIMARY KEY(SPR_ID)
 , CONSTRAINT UNISPR#U#SPR_ID#SPR_KOD 
      UNIQUE(SPR_ID, SPR_KOD);

CREATE TABLE MY_FACT(
   FACT_ID NUMBER(20)
 , FACT_DATE DATE NOT NULL
 , ...
 , FACT_SPR_KOD NUMBER(5) NOT NULL
 , FACT_SPR_ID
 , CONSTRAINT MY_FACT#C#FACT_SPR_KOD#22 
      CHECK (SPR_KOD = 22)
 , CONSTRAINT MY_FACT#R#UNISPR#22
      FOREIGN KEY(SPR_ID, SPR_KOD)
      REFERENCES(SPR_ID, SPR_KOD) );

-- Условие F.FACT_SPR_KOD = US.SPR_KOD указывать не нужно, 
-- поскольку "нерасхождение" обеспечивают: FOREIGN KEY и CHECK
SELECT F.FACT_ID, F.FACT_DATE, UL.SPR_NAME
FROM MY_FACT F, UNISPR US
WHERE F.FACT_SPR_ID = US.SPR_ID;
...
Рейтинг: 0 / 0
02.02.2021, 02:42
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40040754
Фотография Валерий Юринский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валерий Юринский
Участник
L_argo
ptr128
L_argo,

больше всего не люблю такие таблицы из-за того, что во всех таблицах, которые на них ссылаются, приходится хранить не только ссылку на элемент справочник, но и код этого справочника (хотя бы в вычисляемом постоянном поле). Иначе foreign key не сделать.
Если у мультисправочника сделать сквозное ключ-поле, то необязательно.

Ниодна ERP-система foreign key не использует. За ненадобностью.

Зато программисты всегда при деле: заняты поиском и устранений периодически возникающих расхождений.
...
Рейтинг: 0 / 0
02.02.2021, 02:43
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40040787
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
Валерий Юринский
Зато программисты всегда при деле: заняты поиском и устранений периодически возникающих расхождений.
Они в любом случае будут этим заниматься.
Т.к. причина "расхождений" вовсе не по причине отсутствия констрайнт.
...
Рейтинг: 0 / 0
02.02.2021, 10:03
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40040810
Фотография Валерий Юринский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валерий Юринский
Участник
L_argo
Валерий Юринский
Зато программисты всегда при деле: заняты поиском и устранений периодически возникающих расхождений.
Они в любом случае будут этим заниматься.
Т.к. причина "расхождений" вовсе не по причине отсутствия констрайнт.

Здесь я имею в виду наличие "расхождений" именно по причине отсутствия
декларативных ограничений целостности (констрейнтов) типа Foreign Key.
...
Рейтинг: 0 / 0
02.02.2021, 11:22
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40040818
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
Валерий Юринский
L_argo
пропущено...
Они в любом случае будут этим заниматься.
Т.к. причина "расхождений" вовсе не по причине отсутствия констрайнт.

Здесь я имею в виду наличие "расхождений" именно по причине отсутствия
декларативных ограничений целостности (констрейнтов) типа Foreign Key.
И что ?
Допустим надо импортировать csv в 1млн. строк. Среди них есть несколько с неверным ключом.
Импорт через IS пакет напишет ошибку и не вставит ничего.
Твои действия ? :)
...
Рейтинг: 0 / 0
02.02.2021, 11:42
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40040831
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
L_argo
Валерий Юринский
Зато программисты всегда при деле: заняты поиском и устранений периодически возникающих расхождений.
Они в любом случае будут этим заниматься.
Т.к. причина "расхождений" вовсе не по причине отсутствия констрайнт.

В 90+% случаев - именно по этой причине.
...
Рейтинг: 0 / 0
02.02.2021, 12:32
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40040847
Фотография Валерий Юринский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валерий Юринский
Участник
L_argo
Валерий Юринский
пропущено...

Здесь я имею в виду наличие "расхождений" именно по причине отсутствия
декларативных ограничений целостности (констрейнтов) типа Foreign Key.
И что ?
Допустим надо импортировать csv в 1млн. строк. Среди них есть несколько с неверным ключом.
Импорт через IS пакет напишет ошибку и не вставит ничего.
Твои действия ? :)
Очень хорошо. Мусор не попадёт в базу.
Варианты "борьбы":
1) Исправить CSV файл и повторить загрузку.
2) Удалить из CSV-файла неверные строки, остальные загрузить.
Потом разобраться с неправильными данными, исправить их и догрузить.

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

P.S. Что такое "IS пакет"? Это то, что программист написал для загрузки данных из CSV-файла?
...
Рейтинг: 0 / 0
02.02.2021, 12:59
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40040923
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
Валерий Юринский
L_argo
пропущено...
И что ?
Допустим надо импортировать csv в 1млн. строк. Среди них есть несколько с неверным ключом.
Импорт через IS пакет напишет ошибку и не вставит ничего.
Твои действия ? :)
Очень хорошо. Мусор не попадёт в базу.
Варианты "борьбы":
1) Исправить CSV файл и повторить загрузку.
2) Удалить из CSV-файла неверные строки, остальные загрузить.
Потом разобраться с неправильными данными, исправить их и догрузить.

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

P.S. Что такое "IS пакет"? Это то, что программист написал для загрузки данных из CSV-файла?
Теоретег детектед.
1. Найти и исправить ? В 1 млн строк ??? Это была шутка ?
2. Допустим да. Но см. п.1.

Грязные данные нужно проверить. И не только по СЦ. Есть еще недопустимые значения (даты, суммы, пустоты, недопустимые символы, форматирование). Поэтому верификация все равно нужна. И в БД это сделать проще и быстрее всего. Удалить, поправить .. не суть. Часто это делают на промежуточной (stage) таблице.

IS пакет это integration services (mssql). Раньше назывался DTS.
...
Рейтинг: 0 / 0
02.02.2021, 16:26
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40040934
Фотография Валерий Юринский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валерий Юринский
Участник
L_argo
Валерий Юринский
пропущено...
Очень хорошо. Мусор не попадёт в базу.
Варианты "борьбы":
1) Исправить CSV файл и повторить загрузку.
2) Удалить из CSV-файла неверные строки, остальные загрузить.
Потом разобраться с неправильными данными, исправить их и догрузить.

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

P.S. Что такое "IS пакет"? Это то, что программист написал для загрузки данных из CSV-файла?
Теоретег детектед.
1. Найти и исправить ? В 1 млн строк ??? Это была шутка ?
2. Допустим да. Но см. п.1.

Грязные данные нужно проверить. И не только по СЦ.
Есть еще недопустимые значения (даты, суммы, пустоты, недопустимые символы, форматирование).
Поэтому верификация все равно нужна. И в БД это сделать проще и быстрее всего.
Удалить, поправить .. не суть. Часто это делают на промежуточной (stage) таблице.

IS пакет это integration services (mssql). Раньше назывался DTS.
Да, искать кривые строки удобнее в базе данных.
И это нужно делать, используя промежуточную (stage) таблицу.

Отключение ограничений Foreign Key на производственной таблице - это плохой способ.
Такая таблица становится промежуточной (stage) таблицей на время загрузки данных.
Причем, никто не гарантирует, что её Foreign Key удастся быстро включить,
в том числе, из-за неисправленной кривизны данных и размера таблицы,
поскольку данные нужно проверить при включении FK.
...
Рейтинг: 0 / 0
02.02.2021, 17:15
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40040938
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
softwarer
L_argo
пропущено...
Они в любом случае будут этим заниматься.
Т.к. причина "расхождений" вовсе не по причине отсутствия констрайнт.

В 90+% случаев - именно по этой причине.
Речь шла о том, что входные данные содержат ошибки.
И по хорошему, следует эти ошибки устранить до попытки их импорта. Или в момент импорта.

Невставка данных это тоже грубая ошибка.
Толку от той целостности, если клиенту придет счет на ХХХХХ руб. меньше, чем нужно ? :)
...
Рейтинг: 0 / 0
02.02.2021, 17:28
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40041544
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
Albert Oreol, попробуйте оттолкнуться от природы ваших данных.
Типичные вопросы в вашем случае:

* будете ли вы использовать кросс-запросы между сущностями?
(т.е. выборка в один резалтсет данных из разных таблиц)
* предполагается ли масштабирование системы - добавление новых подобных "таблиц", удаление существующих и т.д.
* необходим ли вам аудит данных в этих таблицах?

ну и совсем радикальный вопрос - а точно надо для каждой сущности (исходя из вашего описания), иметь отдельный идентификатор? Или можно запилить сквозной один на всех, и вообще обойтись без категории?
...
Рейтинг: 0 / 0
04.02.2021, 13:07
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40041624
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
L_argo
Речь шла о том, что входные данные содержат ошибки.
И по хорошему, следует эти ошибки устранить до попытки их импорта. Или в момент импорта.

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

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

L_argo
Невставка данных это тоже грубая ошибка.

Вы изначально рассуждаете в какой-то нелепой парадигме того, как вообще организован импорт и какие возможности (не)доступны. С точки зрения "невставки данных" внешние ключи малоинтересны, поскольку их вешают на основные таблицы, а не на стейджинг. Куда интереснее с точки зрения "невставки" случаи типа "в числовом поле содержатся категорически текстовые данные", "в поле varchar(240) нужно впихнуть строку из 256 символов", "в поле даты значение 30.02.2010" итп.
...
Рейтинг: 0 / 0
04.02.2021, 15:11
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40041641
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
softwarer,

Много букф, но суть та же: сначала очищаем, потом вставляем. Про что я выше указал.
Проблема СЦ незначительна на фоне остальных проблем, также указанных выше.

зы: скучно... Тема уныло пережевывается уже не один год без каких либо новых идей и даже фраз.
Зачем обсуждать, если все равно каждый сделает по своему ? :)
...
Рейтинг: 0 / 0
04.02.2021, 15:28
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40041668
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
L_argo

И по хорошему, следует эти ошибки устранить до попытки их импорта. Или в момент импорта.

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


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

Не стоит смешивать импорт данных и запуск данных в бизнес-процесс.

Из основных плюсов:
* вы сможете "подкрутить" бизнес-логику в любой момент и проработать данные заново.
* у вас всегда есть исходники данных для анализа
* модуль загрузки RAW данных не связан никак с бизнес логикой
* легко масштабировать под новые источники данных

Из минусов:
* доп. место требуется для хранения
* нужно нормально прорисовать (хотя бы мысленно) процесс и взаимосвязи между этапами.
...
Рейтинг: 0 / 0
04.02.2021, 15:52
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40041711
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
L_argo
Много букф

Как же Вы работаете, если не в состоянии прочитать семь строчек и понять их смысл?

L_argo
Проблема СЦ незначительна на фоне

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

L_argo
Зачем обсуждать, если все равно каждый сделает по своему ? :)

Чтобы честный чайник, который придёт и прочитает, не решил, что тот бред, который Вы периодически публикуете - это и есть тот единственный вариант, который нужно делать и все делают.
...
Рейтинг: 0 / 0
04.02.2021, 16:43
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40041712
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
Из минусов:
* доп. место требуется для хранения
* нужно нормально прорисовать (хотя бы мысленно) процесс и взаимосвязи между этапами. Это не минусы, т.к. этих факторов не избежать.
...
Рейтинг: 0 / 0
04.02.2021, 16:43
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40041782
Daniel Logovenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daniel Logovenko
Гость
L_argo
Из минусов:
* доп. место требуется для хранения
Это не минусы, т.к. этих факторов не избежать.
Если требуется место для хранения данных грязных - это минус есть.
Этого можно избежать.
Например, организационные меры приняв, чтобы данные были чистые.

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

А вы выделения доп. места для хранения избежали,
когда организацию загрузки данных в место их появления перенесли.
...
Рейтинг: 0 / 0
04.02.2021, 18:56
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40041997
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
Daniel Logovenko
L_argo
пропущено...
Это не минусы, т.к. этих факторов не избежать.

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

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


Любой минус можно обратить в плюс:
* то, что должны быть разнесены модули загрузки и обработки - не спорю, но RAW-data от ваших апстримов - должна быть внутри вашей зоны ответственности, чтоб вы могли оперативно с ними что-то сделать, не дергая смежные приложения/команды/проекты
(к примеру - унесли на нон-прод енв слепок данных и воспроизводите проблему в своей песочнице)
* если вдруг по каким-то причинам у вас возникла непредвиденная ошибка обработки данных (баг в коде, сбой системы, уборщица отключила сервер) - вам достаточно пофиксить эту проблему и перезапустить процесс обработки - данные уже есть.
* "грязные данные" - это по критериям на момент обработки. Если вы храните данные у себя, то при изменении критериев = вы можете уже исторические данные переработать по новой бизнес логике (если это применимо к вашей системе), и уже принести профит бизнесу.
Если же вы данные не храните, то все изменения бизнес почувствует только после внедрения нового функционала = исторические данные вы не сможете переработать.

Ну и архив RAW data можно вынести на более дешевые носители/сжать и т.п. дабы этот самый объем уменьшить, но таки да - вам нужно дополнительное место.
...
Рейтинг: 0 / 0
05.02.2021, 11:05
| Ответить | Цитировать | Написать  
19 сообщений из 44, страница 2 из 2
  2  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Категории или одна таблица
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=40041711&tid=1539819]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 31ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 58ms
get tp. blocked users:
 2ms
others: 274ms
total:  410ms
созд. / загр.: 410ms
x
x
Закрыть


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