Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 эти кривые базы данных...  [new]
Злой Хорек
Guest
Хочу открыть новую тему о сравнении баз, но в необычных условиях т.е. когда у разработчика были кривые руки. Приведу пример всем известной компании или предприятия, для живущих в Москве, интенсивно использующего Оракл и жутко ругающегося на эту систему. Опишу несколько стандартных ситуаций.
1. Система непрерывно имеет проблемы с rollback сегментами. Транзакций много, пиковая нагрузка может достигать нескольких тысяч в секунду. Транзакции небольшие. Но ребята используют около 10 роллбеков. Поэтому имеют непрерывные на snapshot too old когда пытаются делать отчеты. Всю жизнь знал, что больше 4 транзакций на rollback низьзя. Ну, Оракл так рекомендует.
2. Другой цирк, проверка на уникальность там поддерживается на уровне приложения. Делаем запрос на таблицу о существовании подобной записи. Это их начальник где-то прочитал, что PK значительно замедляет работу приложения. Честно говоря не знал
3. Жуткие жалобы на тормознутость Оракла. Когда я спросил их админа - сисадмина (DBA не держат по причине ненадобности, зряплату ему надо платить), который устанавливал Ораклы о настройке производительности. Он мне ответил весьма круто, а что там настраивать? Прочитал документацию за 2-3 часа, выставил параметры для Shared Pool и все. О как!!!
4. Система жутко ненадежная абзац какой-то. У них грохнулся винт. Ну а так как они держали все control file на этом винте то база работать дальше не захотела. Поэтому пришлось поднять архив двухнедельной давности. Ну естественно, жуткие вопли о невозможности восстановления базы. База то не в ARCHIVE режиме. Как я помню во всех книгах по Oracle черным по белому сказано о том, что control file надо хранить на разных дисках. Наверно чукча не читатель, чукча - писатель.
5. И они не используют индексы на основные таблицы. Жутко геморойно, объединять таблицы без индексов наверное.

Сразу прошу - ногами не пинать и на мышиные коврики меня не пускать. Я ничего не придумал. У меня там знакомые работают. Все сущая правда. Если что-то еще о них вспомню - добавлю. Ах да, совсем забыл, они планируют переходить с Oracle на MS SQL, говорят он лучше и быстрее работает.
13 дек 03, 03:24    [458607]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6905
Хех...
https://www.sql.ru/forum/actualthread.aspx?bid=3&tid=37290
https://www.sql.ru/forum/actualthread.aspx?bid=3&tid=37733
https://www.sql.ru/forum/actualthread.aspx?bid=9&tid=34688

Кривые руки разработчика в наше время - отнюдь не необычные условия, к сожалению.
13 дек 03, 11:48    [458653]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
Злой Хорёк
Member

Откуда:
Сообщений: 24
Прочитал последний пост и жутко прикололся с использованием DDL в триггерах и обновлением sys.source$. Спросил сегодня ребят из самого Оракла о таких извратах, ответили что таких программеров надо не лечить а отстреливать, чтоб не размножались :))
13 дек 03, 23:51    [458866]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
brahew
Member

Откуда: 61;90
Сообщений: 724
Да, про альфу писали много интересного....
Тут у нас в команде ярый фоксовик есть, всмысле не клиентов на фоксе лепить, а фокс - рулез и как СУБД для него. Мечтает об одном, когда появятся изменяемые отчеты и фокс будет лучшим на все времена, ну не в этом суть.
У нас развивается(ну или по крайней мере пытаемся это делать) две версии ЗП. На дбф и на скуль, так вот, сколько с ним не бодались по поводу его ненормальности, когда он объясняет как он круто меняет ширину таблиц, всмысле колонок и говорит что скуль говно и тп, потому что повторить весь гемор в нем нельзя и приходится писать заново, хотя как расчетчик - он действительно классный специалист, но то, как он пишет код и проектирует базу, это полнейший п...(по названию топика)
14 дек 03, 02:21    [458886]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6905
Я тут ещё один пример вспомнил - трёхзвенка, простейшей аутентификацией занимается middle-tier, используя пару логин-пароль. Интересная особенность заключалась в том, что в отличие от стандартной схемы с уникальным логином и любым (задаваемым пользователем) паролем, использовалась система неуникального логина и уникального в пределах приложения пароля. О как!
15 дек 03, 10:59    [459419]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
Yet another cat
Member

Откуда: Оттуда же
Сообщений: 631
А вот так крутые мужики пишут запросы.

Я плакаль.
=====
Не дождетесь!
15 дек 03, 15:27    [460005]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
fedd
Member

Откуда: Москва
Сообщений: 33999
а как вам справочник в таблице

fieldid
key01
key02
key03
...
key20
val01
val02
val03
...
val20


изготовитель - крутая фирма банковского ПО, Соединённое Королевство Великобритании и Северной Ирландии.
11 янв 04, 02:20    [486876]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
К этой теме возникает еще один закономерный вопрос - насколько СУБД должна быть устойчива к кривым рукам разработчиков. Например я на личном опыте убедился, что MSSQL к сожалению в случае "дикой" проектировки БД валиться и довольно неплохо. История простая - меня попросили в качестве эксперта посмотреть и оценить, каковы шансы перевести БД MSSQL на другую платформу, мотивируя это нестабильной и тормознутой работой MSSQL. Посмотрев на это "чудо", я порекомендовал прекратить обвинять MSSQL во всех смертных грехах и пересмотреть свои взгляды на проектирование БД и реализацию логики ее работы. Сейчас вот пишу документ-обоснование, доказывающий, что MSSQL тут совсем не причем и смена платформы кроме затраты времени и финансов ни чего больше не принесет.

P.S. А вообще то конечно в этом плане MSSQL немного меня удивил - какие бы не были в БД применены некорректные решения и пусть все бы тормозило, но вот валиться СУБД не должно ни в коем случае, в любом случае надежность работы и хранения данных в таких системах должна быть превыше всего.
11 янв 04, 16:53    [487032]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
к вопросу о стабильности базы :)
Я пару раз наблюдал ситуацию, когда клиентское приложение на VB умудрялось записать в таблице БД некое значение, после которого все становилось раком - ни один селект, затрагивающий определенную странцу данных не выполнялся - сервер "отстреливал" соединение. Лечилось только DBCC CHECKDB.
Насчет кривых рук - согласен.

Пример.
Таблица сделок разных типов (Forex, Fixed Income и т.п.) - ширина 220 полей, из них - порядка 40 полей обозначены как UDF_001 - UDF_040, в которых хранится всякая фигня (поля типа varchar) и мало кто знает, что это за информация.

PS. Сервер 7.0 :)
11 янв 04, 20:20    [487093]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6905
Чтобы Oracle валился от кривого приложения - я такого не встречал. А проблемы с производительностью практически гарантированы.
12 янв 04, 10:19    [487293]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Давайте еще посоревнуемся у кого больше индексов на одну таблицу...)
у меня - 20 (двадцать)...(но автор не я...)))
12 янв 04, 11:31    [487408]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
Если в эту таблицу редко пишут но часто читают, то 20 индексов может быть нормальным - все зависит от ее использования.
12 янв 04, 11:34    [487414]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
как раз нет...и пишут хорошо, и читают замечательно...
6 индексов - вообще не используется...
12 янв 04, 11:44    [487434]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Подумаешь 20 индексов :) В вышеописанной БД в одной таблице было 23 индекса и 12 foreign key, причем из индексов было 4 одинаковых и из foreign key - 7 связей на одну и ту же таблицу по одному и тому же полю :) Я когда эту БД в ASA перегнал, чтобы погонять ее профайлером и дебагером, она бедная устала ругаться в своем окне лога на дублирующие индексы и связи. А еще вчера там смотрел на запрос в ХП, обьединяющий в себя наверное с 30-ник таблиц, по непонятным мне принципам, многие из которых были по обьему с миллионами записей. Запрос тормозил со страшной дурью, Table Scan мелькала тут и там. Я обнаружил, что в запросе некоторые не кислые по обьему таблицы используются по несколько раз, однако не какой смысловой нагрузки не несут, соединяясь между собой один к одному (ID=ID). Убрал ради интереса лишние таблицы из запроса, все стало работать быстро, возвращается вроде все тоже самое. Еще меня порадовали многочисленные NULL поля на Foreign Key, подкидывающие оптимизатору запросов лишнюю работу по их сравнению с NULL. Так же впечатлили скалярные UDF, которые используются в JOIN для связи, получают некий ID, много и муторно делают какие то SELECT в переменные и в итоге на выходе выдают нужный ID :) Если БД переложить на фильм, то уверяю, получился бы просто прекрасный ужастик. "Звонок" и близко бы не стоял. Хотя думаю, если наверное спросить админов, которые сейчас с этой БД работают, думаю им и на фильм ничего перекладывать не надо - скорее всего от этого ужаса они уже давно сошли с ума. Для полного счастья сюда же можно приплюсовать супер-клиента, сделанного в том же ключе ...
12 янв 04, 12:21    [487511]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
а еще меня прикалывает когда справочник содержит в качестве ключевого поля значение NULL, очень прикалывает, когда имена таблиц : TABLE1, TABLE2 ... TABLE153...)
Прикалывает, когда на поля, в которых 1-2 допустимых значения (пол-мужской-женский) заводится отдельная таблица:
select * from TABLES123
INDEXMAINS123 SEX
--------------- ---------------
NULL Не определено
1 M
2 Ж
12 янв 04, 13:15    [487605]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Пол = NULL - это сильно :)
12 янв 04, 13:48    [487683]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
Ptitzz
Member

Откуда:
Сообщений: 51
Конечно отдельная таблица для пола это изврат, но ПОЛ=NULL вполне реально. писал БД для судебно-медицинских лабораторий, так так это вполне вероятно когда заносят информацию об останках и определить пол не возможно - тогда он действительно NULL :(
Главное, чтобы в ДНК ошибки не было
12 янв 04, 14:23    [487805]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
NULL<> NULL - вот в чем вопрос...
По NULL таблицы не объеинить...
12 янв 04, 14:55    [487886]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
А почему кстати отдельная таблица для пола изврат ? Во первых клиентское приложение в виде DBLookup может спрашивать пол без его жесткого вшития в код, во вторых если БД интернациональная, то м/ж не очень катит с точки зрения других языков. Плюс возможны варианты хранения краткого/полного наименования, падежей и т.д.

Опять же я считаю смотря для каких задач это изврат/не изврат. Но вот в Primary Key делать NULL - это однозначный изврат. Слава богу, такое только на Access возможно, обломали радость велосипедистам горе-проектировщикам :)
12 янв 04, 15:08    [487917]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Можно придумать кучу таблиц, где имеется все одно-два допустимых значения.
примеры: Муж/Жен, Резидент/нерезидент,Да/Нет,Физ.лицо/Юр.лицо...
Короче все это перечислять можно долго. Для таких вещей проще прменять
chech constraint AtField (field in 'Yes','No'). ИМХО нефиг тратить ресурсы на foreign key и его поддержку. Ей богу так - эффективней.
12 янв 04, 16:33    [488163]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
Alexander_Chepack
Member

Откуда: London
Сообщений: 22649
автор

Короче все это перечислять можно долго.
Для таких вещей проще прменять
chech constraint AtField (field in 'Yes','No').
ИМХО нефиг тратить ресурсы на foreign key и его поддержку.
Ей богу так - эффективней.


Эффективней (и правильней) в таких случаях применять Rules.
12 янв 04, 17:04    [488215]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
fedd
Member

Откуда: Москва
Сообщений: 33999
а где хранить языковые варианты?
правда, справочник полов и их названий на разных языках просто может быть не привязан форин кеем? все равно их только два.

//а кстати, жизнь прекатсна и отвратительна, полов теперь больше чем два!
12 янв 04, 17:15    [488239]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Языковые варианты....))
Давайте будет так:

code lang value
---- ---- -----

1 1251 M
2 1251 Ж
1 437 M
2 437 F
....



нравицца?

Честно говоря мне такой гемор не нужен.
Если приспичит, но в приложении обработаю...
12 янв 04, 17:36    [488283]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
fedd
Member

Откуда: Москва
Сообщений: 33999
gender

======
genderid lang caseid val
-------- ---- ------ ---

1 ru 1 мужской
2 ru 1 женский
1 ru 2 мужского
2 ru 2 женского
1 en 1 male
2 en 1 female


case
====
caseid lang name
------ ---- ----

1 ru именительный
2 ru родительный
1 en именительный
2 en притяжательный
12 янв 04, 17:48    [488300]     Ответить | Цитировать Сообщить модератору
 Re: эти кривые базы данных...  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Угу, можно и падежи, и сокращения, и языки... и довести все до абсурда...))
Еще и нормализовать все до опуперия, построить индексы по всем полям на все случаи жизни... А потом думать, а чего так все медленно ворочаецца?...
12 янв 04, 17:53    [488308]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить