powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / эти кривые базы данных...
25 сообщений из 49, страница 1 из 2
эти кривые базы данных...
    #32351758
Злой Хорёк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хочу открыть новую тему о сравнении баз, но в необычных условиях т.е. когда у разработчика были кривые руки. Приведу пример всем известной компании или предприятия, для живущих в Москве, интенсивно использующего Оракл и жутко ругающегося на эту систему. Опишу несколько стандартных ситуаций.
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, говорят он лучше и быстрее работает.
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32351791
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хех...\r
/topic/37290\r
/topic/37733\r
/topic/34688\r
\r
Кривые руки разработчика в наше время - отнюдь не необычные условия, к сожалению.
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32351967
Злой Хорёк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Прочитал последний пост и жутко прикололся с использованием DDL в триггерах и обновлением sys.source$. Спросил сегодня ребят из самого Оракла о таких извратах, ответили что таких программеров надо не лечить а отстреливать, чтоб не размножались :))
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32351980
Фотография brahew
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, про альфу писали много интересного....
Тут у нас в команде ярый фоксовик есть, всмысле не клиентов на фоксе лепить, а фокс - рулез и как СУБД для него. Мечтает об одном, когда появятся изменяемые отчеты и фокс будет лучшим на все времена, ну не в этом суть.
У нас развивается(ну или по крайней мере пытаемся это делать) две версии ЗП. На дбф и на скуль, так вот, сколько с ним не бодались по поводу его ненормальности, когда он объясняет как он круто меняет ширину таблиц, всмысле колонок и говорит что скуль говно и тп, потому что повторить весь гемор в нем нельзя и приходится писать заново, хотя как расчетчик - он действительно классный специалист, но то, как он пишет код и проектирует базу, это полнейший п...(по названию топика)
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32352374
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я тут ещё один пример вспомнил - трёхзвенка, простейшей аутентификацией занимается middle-tier, используя пару логин-пароль. Интересная особенность заключалась в том, что в отличие от стандартной схемы с уникальным логином и любым (задаваемым пользователем) паролем, использовалась система неуникального логина и уникального в пределах приложения пароля. О как!
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32352834
Фотография Yet another cat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А вот так крутые мужики пишут запросы.\r
\r
Я плакаль.\r
=====\r
Не дождетесь!
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32372429
Фотография fedd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а как вам справочник в таблице

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

изготовитель - крутая фирма банковского ПО, Соединённое Королевство Великобритании и Северной Ирландии.
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32372535
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
К этой теме возникает еще один закономерный вопрос - насколько СУБД должна быть устойчива к кривым рукам разработчиков. Например я на личном опыте убедился, что MSSQL к сожалению в случае "дикой" проектировки БД валиться и довольно неплохо. История простая - меня попросили в качестве эксперта посмотреть и оценить, каковы шансы перевести БД MSSQL на другую платформу, мотивируя это нестабильной и тормознутой работой MSSQL. Посмотрев на это "чудо", я порекомендовал прекратить обвинять MSSQL во всех смертных грехах и пересмотреть свои взгляды на проектирование БД и реализацию логики ее работы. Сейчас вот пишу документ-обоснование, доказывающий, что MSSQL тут совсем не причем и смена платформы кроме затраты времени и финансов ни чего больше не принесет.

P.S. А вообще то конечно в этом плане MSSQL немного меня удивил - какие бы не были в БД применены некорректные решения и пусть все бы тормозило, но вот валиться СУБД не должно ни в коем случае, в любом случае надежность работы и хранения данных в таких системах должна быть превыше всего.
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32372577
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
к вопросу о стабильности базы :)
Я пару раз наблюдал ситуацию, когда клиентское приложение на VB умудрялось записать в таблице БД некое значение, после которого все становилось раком - ни один селект, затрагивающий определенную странцу данных не выполнялся - сервер "отстреливал" соединение. Лечилось только DBCC CHECKDB.
Насчет кривых рук - согласен.

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

PS. Сервер 7.0 :)
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32372737
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чтобы Oracle валился от кривого приложения - я такого не встречал. А проблемы с производительностью практически гарантированы.
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32372818
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Давайте еще посоревнуемся у кого больше индексов на одну таблицу...)
у меня - 20 (двадцать)...(но автор не я...)))
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32372823
andsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если в эту таблицу редко пишут но часто читают, то 20 индексов может быть нормальным - все зависит от ее использования.
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32372839
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
как раз нет...и пишут хорошо, и читают замечательно...
6 индексов - вообще не используется...
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32372906
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Подумаешь 20 индексов :) В вышеописанной БД в одной таблице было 23 индекса и 12 foreign key, причем из индексов было 4 одинаковых и из foreign key - 7 связей на одну и ту же таблицу по одному и тому же полю :) Я когда эту БД в ASA перегнал, чтобы погонять ее профайлером и дебагером, она бедная устала ругаться в своем окне лога на дублирующие индексы и связи. А еще вчера там смотрел на запрос в ХП, обьединяющий в себя наверное с 30-ник таблиц, по непонятным мне принципам, многие из которых были по обьему с миллионами записей. Запрос тормозил со страшной дурью, Table Scan мелькала тут и там. Я обнаружил, что в запросе некоторые не кислые по обьему таблицы используются по несколько раз, однако не какой смысловой нагрузки не несут, соединяясь между собой один к одному (ID=ID). Убрал ради интереса лишние таблицы из запроса, все стало работать быстро, возвращается вроде все тоже самое. Еще меня порадовали многочисленные NULL поля на Foreign Key, подкидывающие оптимизатору запросов лишнюю работу по их сравнению с NULL. Так же впечатлили скалярные UDF, которые используются в JOIN для связи, получают некий ID, много и муторно делают какие то SELECT в переменные и в итоге на выходе выдают нужный ID :) Если БД переложить на фильм, то уверяю, получился бы просто прекрасный ужастик. "Звонок" и близко бы не стоял. Хотя думаю, если наверное спросить админов, которые сейчас с этой БД работают, думаю им и на фильм ничего перекладывать не надо - скорее всего от этого ужаса они уже давно сошли с ума. Для полного счастья сюда же можно приплюсовать супер-клиента, сделанного в том же ключе ...
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32372982
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а еще меня прикалывает когда справочник содержит в качестве ключевого поля значение NULL, очень прикалывает, когда имена таблиц : TABLE1, TABLE2 ... TABLE153...)
Прикалывает, когда на поля, в которых 1-2 допустимых значения (пол-мужской-женский) заводится отдельная таблица:
select * from TABLES123
INDEXMAINS123 SEX
--------------- ---------------
NULL Не определено
1 M
2 Ж
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32373044
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пол = NULL - это сильно :)
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32373145
Фотография Ptitzz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Конечно отдельная таблица для пола это изврат, но ПОЛ=NULL вполне реально. писал БД для судебно-медицинских лабораторий, так так это вполне вероятно когда заносят информацию об останках и определить пол не возможно - тогда он действительно NULL :(
Главное, чтобы в ДНК ошибки не было
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32373207
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NULL<> NULL - вот в чем вопрос...
По NULL таблицы не объеинить...
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32373231
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А почему кстати отдельная таблица для пола изврат ? Во первых клиентское приложение в виде DBLookup может спрашивать пол без его жесткого вшития в код, во вторых если БД интернациональная, то м/ж не очень катит с точки зрения других языков. Плюс возможны варианты хранения краткого/полного наименования, падежей и т.д.

Опять же я считаю смотря для каких задач это изврат/не изврат. Но вот в Primary Key делать NULL - это однозначный изврат. Слава богу, такое только на Access возможно, обломали радость велосипедистам горе-проектировщикам :)
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32373431
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Можно придумать кучу таблиц, где имеется все одно-два допустимых значения.
примеры: Муж/Жен, Резидент/нерезидент,Да/Нет,Физ.лицо/Юр.лицо...
Короче все это перечислять можно долго. Для таких вещей проще прменять
chech constraint AtField (field in 'Yes','No'). ИМХО нефиг тратить ресурсы на foreign key и его поддержку. Ей богу так - эффективней.
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32373473
Alexander_Chepack
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор
Короче все это перечислять можно долго.
Для таких вещей проще прменять
chech constraint AtField (field in 'Yes','No').
ИМХО нефиг тратить ресурсы на foreign key и его поддержку.
Ей богу так - эффективней.

Эффективней (и правильней) в таких случаях применять Rules.
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32373494
Фотография fedd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а где хранить языковые варианты?
правда, справочник полов и их названий на разных языках просто может быть не привязан форин кеем? все равно их только два.

//а кстати, жизнь прекатсна и отвратительна, полов теперь больше чем два!
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32373528
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Языковые варианты....))
Давайте будет так:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
code lang  value
 ----  ---- -----
 
 1       1251  M
 2       1251  Ж
 1       437   M
 2       437   F
....



нравицца?

Честно говоря мне такой гемор не нужен.
Если приспичит, но в приложении обработаю...
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32373544
Фотография fedd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
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  притяжательный
...
Рейтинг: 0 / 0
эти кривые базы данных...
    #32373548
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Угу, можно и падежи, и сокращения, и языки... и довести все до абсурда...))
Еще и нормализовать все до опуперия, построить индексы по всем полям на все случаи жизни... А потом думать, а чего так все медленно ворочаецца?...
...
Рейтинг: 0 / 0
25 сообщений из 49, страница 1 из 2
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / эти кривые базы данных...
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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