Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Проектирование БД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10   вперед  Ctrl      все
 Антипаттерны проектирования РСУБД  [new]
конечно Вася
Member

Откуда: Брянщина
Сообщений: 54
Коллеги,
здравствуйте.

Кто-нибудь может поделиться антипаттернами проектирования БД?
В том смысле, что физическая модель БД выглядит достойно, но при администрировании наполняющаяся база, страдает тем фактом, что возникает глюк за глюком и багом погоняет. Затем патч физической модели, тишина, но вновь ситуация повторяется.
Рад любому опыту.
Есл же при этом есть (поделитесь) книгой/URL/webinar-ом --спасибо вдвойне.


С уважением,
Игорь.
23 июн 18, 07:50    [21514839]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
L_argo
Member

Откуда:
Сообщений: 155
Популярно:
1. Бездумное добавление новых колонок в ключевые таблицы и дальнейшие проблемы с миграцией данных или обменом между аналогичными БД.

2. Неудачный выбор первичного ключа: ключ делают сложносоставным и в итоге копируют его по куче таблиц.
3. Неудачный тип поля, н-р числовой для "Номер Документа" или недостаточной ширины.
4. Попытка использовать естественные ключи (н-р ФИО или логин)
5. Активное использование триггеров.
6. Использование новейших фич СУБД, без которых легко обойтись. И вообще не стоит использовать новейшие версии. У заказчика их может не оказаться.
23 июн 18, 11:05    [21514955]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
SERG1257
Member

Откуда:
Сообщений: 2546
конечно Вася
Есл же при этом есть (поделитесь) книгой/URL/webinar-ом --спасибо вдвойне.


SQL Antipatterns
Avoiding the Pitfalls of Database Programming
By Bill Karwin
23 июн 18, 18:26    [21515455]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
L_argo
Member

Откуда:
Сообщений: 155
Есть такое мнение с которым я согласен:
Проектируйте систему исходя из того, как будете выводить инфу в отчеты.
Т.к. разного рода отчеты (это не обязательно печатные формы) это конечная ценность любой системы.
То, для чего их создают. :)
23 июн 18, 20:51    [21515666]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
hVostt
Member

Откуда:
Сообщений: 14025
L_argo
Есть такое мнение с которым я согласен:
Проектируйте систему исходя из того, как будете выводить инфу в отчеты.
Т.к. разного рода отчеты (это не обязательно печатные формы) это конечная ценность любой системы.
То, для чего их создают. :)


Не совсем верно. Если ввод данных прогонять через события, или журнал (например, Kafka), то можно делать проекции под любые, самые дебильные отчёты.

Да и отчёты в большом их количестве, это область enterprise в основном.

Ценность любой системы состоит в экономическом эффекте. Если его нет, или он незначителен, то всеми отчётами можно лишь подтереться.
24 июн 18, 00:28    [21516072]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
hVostt
Member

Откуда:
Сообщений: 14025
конечно Вася,

Основной антипаттерн: увлечение овер-моделированием БД. Страдают в основном немножко упоротые dba, или недоучки, для которых это является самоцелью.

«Глюк за глюком и багом погоняет» -- это не скорее не антипаттерн, а банальное отсутствие знаний и опыта, попросту непрофессионализм. Никаким сводом антипаттернов тут не поможешь.
24 июн 18, 00:33    [21516077]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
Кнюпель
Member

Откуда:
Сообщений: 8
- Магические константы в ключах
- Магические константы управляющие логикой "к какой таблице джойним вот этот столбец"
- Триггеры (за исключением логирования)
- Недостаточная/неверная нормализация
- Избыточная нормализация
- ХМL типы данных вместо нормализации
- Неверно сделаное наследование сущностей
24 июн 18, 02:15    [21516112]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
StalkerS
Member

Откуда: Nowhere
Сообщений: 1338
Я-бы сказал в основном дублирование данных
24 июн 18, 03:59    [21516133]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
конечно Вася
Member

Откуда: Брянщина
Сообщений: 54
Друзья, спасибо!
24 июн 18, 07:44    [21516168]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
конечно Вася
Member

Откуда: Брянщина
Сообщений: 54
SERG1257
конечно Вася
Есл же при этом есть (поделитесь) книгой/URL/webinar-ом --спасибо вдвойне.


SQL Antipatterns
Avoiding the Pitfalls of Database Programming
By Bill Karwin


Что O'REILLY жив и живее всех живых (40000 материалов) отдельное спасибо.
Жаль, что перестали переводить.

С уважением,
Игорь Никольский.
24 июн 18, 07:49    [21516171]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
конечно Вася
Member

Откуда: Брянщина
Сообщений: 54
L_argo
Есть такое мнение с которым я согласен:
Проектируйте систему исходя из того, как будете выводить инфу в отчеты.
Т.к. разного рода отчеты (это не обязательно печатные формы) это конечная ценность любой системы.
То, для чего их создают. :)


Отсутствие PRINT даже в супер сложных расчётах на векторном CRAY MVP (мог забыть точное название модели), давало компилятору право мгновенно завершить расчёты.
24 июн 18, 07:53    [21516172]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
казинак
Member

Откуда:
Сообщений: 1130
самое неудачное - это когда на реляционную модель пытаются натянуть ООП, графы и др универсальные модели
например:
в строку засунуть сразу много значений через разделитель и держать в одном поле
или вместо полей делать строки а потом транспонировать
или (случай из Кайта) жависты решили не париться с таблицами а просто сериализовывали объекты и сохраняли в LOB, ну а пользователи не могли из этого ведра с битами получить отчеты стандартными report designer-ами


пример эпик фейла из книги Oracle Insights: Tales of the Oak Table
https://www.red-gate.com/simple-talk/opinion/opinion-pieces/bad-carma/
Here are some facts about the Vision system:

The data model comprised a single table named DATA.
The DATA table had 240+ columns.
The primary key column was a numeric named SYSNO.
Columns existed for attributes, such as TYPE, SUBTYPE, CATEGORY, SUBCATEGORY, STATUS, SUBSTATUS, GROUP, and OWNER, which were intended to fully describe what type, category, or grouping to which the row belonged. Each of these columns were themselves SYSNOs, joining back to other rows in DATA for more detail.
The majority of columns in DATA provided sequencing, descriptive text, names, values, amounts, dates entered and modified, and so on. Some of these columns would be named and data-typed appropriately, while others were “generic spare” columns, several for each datatype.
When the Vision system was finally decommissioned, a year after it went into production, the DATA table consumed 50GB of space.
40+ associated indexes consumed another 250GB of space.
24 июн 18, 08:04    [21516173]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
tip78
Member

Откуда: Москва
Сообщений: 971
по сути все анти-паттерны сводятся к непониманию, как работает реляционная БД
если оставить совсем клинические случаи, то:
в первую очередь надо понять про нормализацию, что связывание таблиц это норма (с), это работает хорошо, реляционная алгебра рулит
Что разделение данных по таблицам это ок, для скорости данные должны быть маленькими
ИНДЕКСЫ увеличивают размер таблицы и тормозят инзерты (первый же индекс замедляет инзерт ~ в 2 раза)
потом транзакции неплохо бы понимать и как БД с ними справляется
А потом узнать, что репликация это распределённые транзакции и это ВСЕГДА тяжело для БД.




24 июн 18, 10:29    [21516284]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
казинак
Member

Откуда:
Сообщений: 1130
tip78
ИНДЕКСЫ увеличивают размер таблицы

Это где так?
в оракле индексы - это совсем отдельные от таблиц структуры,
насколько помню в мсскл, db2, postgre - также
tip78
А потом узнать, что репликация это распределённые транзакции и это ВСЕГДА тяжело для БД.

между репликацией и распределенными транзакциями (2PC) общего только то, что в этом участвуют несколько баз
это разные понятия
24 июн 18, 11:13    [21516318]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2455
конечно Вася
Коллеги,
здравствуйте.

Кто-нибудь может поделиться антипаттернами проектирования БД?
В том смысле, что физическая модель БД выглядит достойно, но при администрировании наполняющаяся база, страдает тем фактом, что возникает глюк за глюком и багом погоняет. Затем патч физической модели, тишина, но вновь ситуация повторяется.
Рад любому опыту.
Есл же при этом есть (поделитесь) книгой/URL/webinar-ом --спасибо вдвойне.


С уважением,
Игорь.

1. Что Вы понимаете под физической моделью, которая "выглядит достойно"?
2. По каким формальным критериям она выглядит достойно?
24 июн 18, 12:10    [21516399]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2455
L_argo
Популярно:
1. Бездумное добавление новых колонок в ключевые таблицы и дальнейшие проблемы с миграцией данных или обменом между аналогичными БД.

2. Неудачный выбор первичного ключа: ключ делают сложносоставным и в итоге копируют его по куче таблиц.
3. Неудачный тип поля, н-р числовой для "Номер Документа" или недостаточной ширины.
4. Попытка использовать естественные ключи (н-р ФИО или логин)
5. Активное использование триггеров.
6. Использование новейших фич СУБД, без которых легко обойтись. И вообще не стоит использовать новейшие версии. У заказчика их может не оказаться.

1. В СУБД нет никаких проблем, даже, теоретических с добавлением любых свойств любых типов сущностей. Возможно, Ввы пишете о какой-то специфической системе. Но, зачем использовать систему с такими проблемами?
2. В БД, нет никаких ключей в принципе. Опять речь о какой-то специфической системе.
3. Как конкретно это приводит к "глюком за глюком и багом погоняет"?
4. См. п. 2. Вы уверены, что автор темы использует такую странную систему?
5. Проведите, пожалуйста, формальную границу, между пассивным использованием триггеров (когда нет "глюком за глюком и багом погоняет") и активным - когда "глюком за глюком и багом погоняет".
6. Приведите пример старинной фичи СУБД, без которой нельзя обойтись.
24 июн 18, 12:18    [21516409]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
tip78
Member

Откуда: Москва
Сообщений: 971
казинак
tip78
ИНДЕКСЫ увеличивают размер таблицы

Это где так?
в оракле индексы - это совсем отдельные от таблиц структуры,
насколько помню в мсскл, db2, postgre - также

имеется ввиду таблица самих индексов
и да, это таблица (в БД всё таблицы), а не "отдельная эфемерная структура"
распухшая таблица = худший поиск

tip78
А потом узнать, что репликация это распределённые транзакции и это ВСЕГДА тяжело для БД.

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

ну так вот то что транзакцию надо размазывать на несколько шардов существенно усложняет процесс обработки
24 июн 18, 13:05    [21516485]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 24802
tip78
казинак
пропущено...

Это где так?
в оракле индексы - это совсем отдельные от таблиц структуры,
насколько помню в мсскл, db2, postgre - также

имеется ввиду таблица самих индексов
и да, это таблица (в БД всё таблицы), а не "отдельная эфемерная структура"
распухшая таблица = худший поиск
А большинство почему-то думают, что структура индексов иерархическая (древовидная): сбалансированное дерево.
Это если не брать индексы по XML, columnstore и т.п.

tip78
пропущено...

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

ну так вот то что транзакцию надо размазывать на несколько шардов существенно усложняет процесс обработки
Смешались в кучу фрагментация (шардинг) и репликация.
А об чём мысль - мне не понятно.
24 июн 18, 13:18    [21516499]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 24802
tip78,

возможно Вы хотели написать, что в БД всё страницы? Тогда да, индекс - это набор страниц
24 июн 18, 13:24    [21516513]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
ChA
Member

Откуда: Москва
Сообщений: 10531
конечно Вася
SERG1257

SQL Antipatterns
Avoiding the Pitfalls of Database Programming
By Bill Karwin
Что O'REILLY жив и живее всех живых (40000 материалов) отдельное спасибо.
Жаль, что перестали переводить.
Программирование баз данных SQL. Типичные ошибки и их устранение
24 июн 18, 13:35    [21516536]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
Benny Blanco
Member

Откуда:
Сообщений: 519
Я встречал такое: все справочники засовываются в однут таблицу (география, описания типов продуктовых кодов, сами продуктовые коды и вся остальная мелочевка). А в таблице Code, Code Type, Code description, Code label, locale id. И в одну таблицу намешиваются для всех языков и города, Москва, Moscow, и описания продуктовых классов, и описания кодов. И всё остальное.
При этом есть ещё start date и end date. И статусы.
24 июн 18, 14:35    [21516587]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
hVostt
Member

Откуда:
Сообщений: 14025
Бредятина
2. В БД, нет никаких ключей в принципе. Опять речь о какой-то специфической системе.


Это в какой реальности?

Бредятина
3. Как конкретно это приводит к "глюком за глюком и багом погоняет"?


Для человека, который имеет хоть малейший опыт работы с БД очевидно, что например выбор текстового поля для хранения числовых значений или даты/времени, может привести к внезапным проблемам.
24 июн 18, 17:43    [21516823]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
tip78
Member

Откуда: Москва
Сообщений: 971
skyANA
tip78
пропущено...

имеется ввиду таблица самих индексов
и да, это таблица (в БД всё таблицы), а не "отдельная эфемерная структура"
распухшая таблица = худший поиск
А большинство почему-то думают, что структура индексов иерархическая (древовидная): сбалансированное дерево.

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

tip78
пропущено...

ну так вот то что транзакцию надо размазывать на несколько шардов существенно усложняет процесс обработки
Смешались в кучу фрагментация (шардинг) и репликация.
А об чём мысль - мне не понятно.

Ну так какие ваши годы.
зы: шардинг это НЕ фрагментация.

автор
возможно Вы хотели написать, что в БД всё страницы? Тогда да, индекс - это набор страниц

в БД всё биты (bits), так себе и запишите.
24 июн 18, 19:45    [21517026]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 8033
tip78
зы: шардинг это НЕ фрагментация.

Глупая статья - у автора-таки каша в голове. Но да, хотя бы не пишет что репликация обязана "размазывать транзакции на несколько шардов" :)
24 июн 18, 20:07    [21517067]     Ответить | Цитировать Сообщить модератору
 Re: Антипаттерны проектирования РСУБД  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 24802
tip78
skyANA
пропущено...
А большинство почему-то думают, что структура индексов иерархическая (древовидная): сбалансированное дерево.

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

пропущено...
Смешались в кучу фрагментация (шардинг) и репликация.
А об чём мысль - мне не понятно.

Ну так какие ваши годы.
зы: шардинг это НЕ фрагментация.

автор
возможно Вы хотели написать, что в БД всё страницы? Тогда да, индекс - это набор страниц

в БД всё биты (bits), так себе и запишите.

Решили ещё и невежеством блеснуть. Я не удивлён

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

А предположить, что я за 15 лет никогда не хранил древовидную структуру в БД и не использовал NoSQL - просто глупо.
Особенно учитывая то, что моё резюме элементарно найти на сайте.

Я намекал на то, что шардинг - это не репликация. Шардинг - это распределение, фрагментация. По разному переводят в разных изданиях, но суть одна.

В БД есть подсистема хранения, она оперирует страницами. Таблицы - это логический блок.
Так себе и запишите: подсистема хранения, - на досуге почитаете
24 июн 18, 20:17    [21517090]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10   вперед  Ctrl      все
Все форумы / Проектирование БД Ответить