ReSQL.ru
     
powered by simpleCommunicator - 2.0.48     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Категории или одна таблица
44 сообщений из 44, показаны все 2 страниц
  все  
Категории или одна таблица
    #39952637
Albert Oreol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Albert Oreol
Гость
Имеется около 6-10 таблиц вида:
Код: plsql
1.
2.
3.
4.
5.
6.
CREATE TABLE `tablet_**` (
  `id` mediumint(8) UNSIGNED NOT NULL,
  `id` tinyint(3) UNSIGNED NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- UNIQUE KEY `_UNIQUE` (`id`,`id2`),



Всё же думаю переделать в одну таблицу, но с уже добавлением, скажем так, поля с категорией:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
CREATE TABLE `tablet` (
  `id` mediumint(8) UNSIGNED NOT NULL,
  `cat` varchar(12) NOT NULL,
  `id2` tinyint(3) UNSIGNED NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- UNIQUE KEY `_UNIQUE` (`id`,`cat`,`id2`),



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

Стоит ли так переделать таблицы? Не слишком сильно это скажется на время выборки? В каждой разное количество данных, но в общей сумме где-то 35+ тысяч записей.
...
Рейтинг: 0 / 0
28.04.2020, 22:58
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #39952645
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Albert Oreol
Стоит ли так переделать таблицы?
Нет, не стоит.
Однажды вам понадобится сделать разное количество поле/типы данных и придется городить костыли.
А профита никакого не видно.
...
Рейтинг: 0 / 0
28.04.2020, 23:23
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #39952670
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Ищите по форуму на тему 'универсальный справочник'

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

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

Дальше - рано или поздно возникнет необходимость работать с разными сущностями (типа старых таблиц)
Вы налепите вьюх типа select * from mytable where cat=`mycat` и экономии на числе объектов не будет от слова совсем.

овчинка выделки не стоит.
...
Рейтинг: 0 / 0
29.04.2020, 05:11
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #39952750
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KreatorXXI
Участник
Albert Oreol,

я против т.н. универсального справочника. Но надо посмотреть на сущности. Что именно в таблицах? Бывает есть смысл, когда запрос легче делать по одной таблице нежели по 6-10. Озвучьте конкретику. Смущает, что у Вас полей в таблицах мало. Поэтому вряд ли это справочники. И есть вероятность, что они одинаковой сущности.
...
Рейтинг: 0 / 0
29.04.2020, 11:10
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033383
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
SERG1257
Ищите по форуму на тему 'универсальный справочник'

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

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

Дальше - рано или поздно возникнет необходимость работать с разными сущностями (типа старых таблиц)
Вы налепите вьюх типа select * from mytable where cat=`mycat` и экономии на числе объектов не будет от слова совсем.

овчинка выделки не стоит.
Есть справочников много и если все они заведома одинаковые по структуре (обычно это минисправочники ключ+значение), то вполне их можно сделать на базе 1-й таблицы. Написать единый код, который будет работать хоть с тыщей минисправочников, в т.ч. с теми которых еще нет в ТЗ.
Для создания нового (мини)справочника не нужны будут DDL-команды и админские БД-права.
Это полезно для непрерывно эволюционирующих систем класса ERP/CRM и е-магазинных витрин.

Если вдруг понадобится добавить в него новые поля... Ну чтож. Ничто не мешает сделать ему полноценную отдельную таблицу.

зы: Интересно, на каком нибудь OZON-е фильтры слева это отдельные таблички ? Чо серьёзна ?????
...
Рейтинг: 0 / 0
04.01.2021, 14:19
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033421
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
L_argoЭто полезно для непрерывно эволюционирующих систем класса ERP/CRM и е-магазинных витринА для остальных это выглядит как тюнингованый жигуль: заниженный, с огромным антикрылом и маленьким рулем.
...
Рейтинг: 0 / 0
04.01.2021, 17:30
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033436
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
L_argo,

больше всего не люблю такие таблицы из-за того, что во всех таблицах, которые на них ссылаются, приходится хранить не только ссылку на элемент справочник, но и код этого справочника (хотя бы в вычисляемом постоянном поле). Иначе foreign key не сделать.
...
Рейтинг: 0 / 0
04.01.2021, 18:23
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033447
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vmag
Участник
KreatorXXI
надо посмотреть на сущности. Что именно в таблицах?

+
и какие могут быть перспективы...
А пока похоже на вопрос типа если пропеллер крутить быстро- взлетит или не взлетит?...
- если пропеллер это нож мясорубки, прикрученной к столу - то не взлетит...
...
Рейтинг: 0 / 0
04.01.2021, 18:50
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033461
harvest6
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
harvest6
Гость
Albert OreolОни никак не пересекаются и не связаны, одинаковые данные, просто для различных вещей.

Получается одна сущность с одним и тем же набором атрибутов?
Тогда, целесообразней хранить их в одной таблице. Категории - в другой. Итого две таблицы.
...
Рейтинг: 0 / 0
04.01.2021, 19:48
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033481
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Albert Oreol
Стоит ли так переделать таблицы?

Зависит от того, что будет дальше. Если через месяц выбросишь эту поделку и забудешь - да, стоит. Если не выбросишь, но хочется через три года получать матюки на голову того, кто это придумал - тоже стоит.
...
Рейтинг: 0 / 0
04.01.2021, 22:08
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033568
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
ptr128
L_argo,

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

Ниодна ERP-система foreign key не использует. За ненадобностью.
...
Рейтинг: 0 / 0
05.01.2021, 11:25
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033573
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
L_argo
Если у мультисправочника сделать сквозное ключ-поле, то необязательно.

Какой смысл в таком контроле целостности, если ссылка может указывать на запись любой категории, а не только нужной?

L_argo
Ниодна

Почитайте тут в разделе "Апелляция к очевидности, ложная авторитетность".
Если Вы чего-то не знаете, то из этого вовсе не следует, что этого не существует )))

Иными словами, трехуровневые системы, расчитанные на работу с более чем одним сервером баз данных одновременно, вынужденны контролировать ссылочную целостность на уровне сервера приложений, так как средствами БД контролировать ссылочную целостность между разными серверами баз данных проблематично. То есть, foreign key все равно существуют и активно используются, только не на уровне БД, а на уровне сервера приложений.
...
Рейтинг: 0 / 0
05.01.2021, 12:00
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033604
Serguei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Serguei
Участник
L_argo
Ниодна ERP-система foreign key не использует. За ненадобностью.


Ишь ты.... вот ведь... :)

Откуда такие категоричные выводы? Если вы лично не используете foreign key , это не означает, что никто не использует.
Можете назвать причины по которым считаете, что foreign key это ненужный рудимент?
...
Рейтинг: 0 / 0
05.01.2021, 14:06
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033619
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
авторТо есть, foreign key все равно существуют и активно используются, только не на уровне БД, а на уровне сервера приложений . Именно так. Проверка на уровне БД неудобна или не нужна. В ряде случаев невозможна.

Если чо, изначально мой пост был именно про СЦ на уровне БД .
Разумеется, что подобные проверки делают, но не с помощью бд-констрайнт foreign key.

Иногда foreign key нарушен умышленно, н-р если =0 принято в системе как отсутствие ссылки.

Что-то про OZON никто ничего не ответил... :-)
...
Рейтинг: 0 / 0
05.01.2021, 14:54
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033621
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Serguei
Откуда такие категоричные выводы? Если вы лично не используете foreign key , это не означает, что никто не использует. Можете назвать причины по которым считаете, что foreign key это ненужный рудимент?

Человека просто несёт. Если мне не изменяет память, в прошлый раз я ткнул его носом в кучу ERP, которые используют FK. Результат ожидаемый - ушёл в тень, а через какое-то время вылезает и несёт ту же самую пургу. Было бы странно ожидать другой результат.
...
Рейтинг: 0 / 0
05.01.2021, 14:56
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033624
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
softwarer,
в реальности, действительно есть ERP, которые не используют foreign key на уровне БД. Но тогда они используют foreign key на уровне сервера приложений. Причины я описал выше. 22258865
...
Рейтинг: 0 / 0
05.01.2021, 15:00
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033628
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
L_argo
Разумеется, что подобные проверки делают, но не с помощью бд-констрайнт foreign key.

Следовательно вопрос остается открытым:
ptr128
L_argo
Если у мультисправочника сделать сквозное ключ-поле, то необязательно.

Какой смысл в таком контроле целостности, если ссылка может указывать на запись любой категории, а не только нужной?
...
Рейтинг: 0 / 0
05.01.2021, 15:04
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033633
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ptr128
softwarer,
в реальности, действительно есть ERP, которые не используют foreign key на уровне БД.

Вы видите разницу между утверждениями "Есть ERP, которые не используют" и "Ни одна ERP не использует"?
...
Рейтинг: 0 / 0
05.01.2021, 15:09
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033635
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
Какой смысл в таком контроле целостности, если ссылка может указывать на запись любой категории, а не только нужной?Если ссылка указывает на неверную запись из правильной категории (н-р яблоки в овощах) это тоже ошибка. И чо ?

Ссылки на неверные категории достаточно легко отловить и исправить с помощью обычного SQL.

При наличии же жесткой БД-шной СЦ большая заливка данных может вообще зафейлиться целиком. А на поиск причин может уйти гора времени.
...
Рейтинг: 0 / 0
05.01.2021, 15:12
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033637
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
L_argo
Участник
Вы видите разницу между утверждениями "Есть ERP, которые не используют" и "Ни одна ERP не использует"? Возможно такие ERP все таки есть. Но их доля на рынке исчезающе мала.
Настолько мала, что нет смысла их упоминать, как значимые.
...
Рейтинг: 0 / 0
05.01.2021, 15:15
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033651
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
softwarer
Вы видите разницу между утверждениями "Есть ERP, которые не используют" и "Ни одна ERP не использует"?

Вижу и писал об этом 22258865
...
Рейтинг: 0 / 0
05.01.2021, 16:09
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033652
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
L_argo
Какой смысл в таком контроле целостности, если ссылка может указывать на запись любой категории, а не только нужной?
Если ссылка указывает на неверную запись из правильной категории (н-р яблоки в овощах) это тоже ошибка. И чо ?

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

L_argo

Ссылки на неверные категории достаточно легко отловить и исправить с помощью обычного SQL.

Но сначала покувыркавшись часик-другой, разбираясь почему в двух отчетах итоги разные. Спасибо, не надо )
...
Рейтинг: 0 / 0
05.01.2021, 16:12
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033760
Serguei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Serguei
Участник
ptr128
softwarer,
в реальности, действительно есть ERP, которые не используют foreign key на уровне БД. Но тогда они используют foreign key на уровне сервера приложений. Причины я описал выше. 22258865


Зачем такая категоричность? Данное утверждение было бы верно, если бы вы добавили "из числа известных лично мне" ;)
...
Рейтинг: 0 / 0
06.01.2021, 07:53
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40033768
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
Serguei,

Ваше заявление не было бы пустым звоном, если бы Вы привели пример хотя бы одной ERP, не контролирующей ссылочную целостность ни на уровне БД, ни на уровне приложения )))
...
Рейтинг: 0 / 0
06.01.2021, 10:12
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #40034139
Serguei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Serguei
Участник
ptr128
Ваше заявление не было бы пустым звоном, если бы Вы привели пример хотя бы одной ERP, не контролирующей ссылочную целостность ни на уровне БД, ни на уровне приложения )))


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

Моя система контролирует целостность данных на уровне БД и на уровне сервера приложений.
...
Рейтинг: 0 / 0
08.01.2021, 13:33
| Ответить | Цитировать | Написать  
Категории или одна таблица
    #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
| Ответить | Цитировать | Написать  
44 сообщений из 44, показаны все 2 страниц
  все  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Категории или одна таблица
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=32&tid=1539819]:
 0ms
get settings:
 8ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 74ms
get topic data:
 12ms
get forum data:
 2ms
get page messages:
 67ms
get tp. blocked users:
 2ms
others: 241ms
total:  429ms
созд. / загр.: 429ms
x
x
Закрыть


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