Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Хочу открыть новую тему о сравнении баз, но в необычных условиях т.е. когда у разработчика были кривые руки. Приведу пример всем известной компании или предприятия, для живущих в Москве, интенсивно использующего Оракл и жутко ругающегося на эту систему. Опишу несколько стандартных ситуаций. 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.12.2003, 03:24 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Хех...\r /topic/37290\r /topic/37733\r /topic/34688\r \r Кривые руки разработчика в наше время - отнюдь не необычные условия, к сожалению. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2003, 11:48 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Прочитал последний пост и жутко прикололся с использованием DDL в триггерах и обновлением sys.source$. Спросил сегодня ребят из самого Оракла о таких извратах, ответили что таких программеров надо не лечить а отстреливать, чтоб не размножались :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2003, 23:51 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Да, про альфу писали много интересного.... Тут у нас в команде ярый фоксовик есть, всмысле не клиентов на фоксе лепить, а фокс - рулез и как СУБД для него. Мечтает об одном, когда появятся изменяемые отчеты и фокс будет лучшим на все времена, ну не в этом суть. У нас развивается(ну или по крайней мере пытаемся это делать) две версии ЗП. На дбф и на скуль, так вот, сколько с ним не бодались по поводу его ненормальности, когда он объясняет как он круто меняет ширину таблиц, всмысле колонок и говорит что скуль говно и тп, потому что повторить весь гемор в нем нельзя и приходится писать заново, хотя как расчетчик - он действительно классный специалист, но то, как он пишет код и проектирует базу, это полнейший п...(по названию топика) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2003, 02:21 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Я тут ещё один пример вспомнил - трёхзвенка, простейшей аутентификацией занимается middle-tier, используя пару логин-пароль. Интересная особенность заключалась в том, что в отличие от стандартной схемы с уникальным логином и любым (задаваемым пользователем) паролем, использовалась система неуникального логина и уникального в пределах приложения пароля. О как! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2003, 10:59 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
А вот так крутые мужики пишут запросы.\r \r Я плакаль.\r =====\r Не дождетесь! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2003, 15:27 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
а как вам справочник в таблице fieldid key01 key02 key03 ... key20 val01 val02 val03 ... val20 изготовитель - крутая фирма банковского ПО, Соединённое Королевство Великобритании и Северной Ирландии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2004, 02:20 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
К этой теме возникает еще один закономерный вопрос - насколько СУБД должна быть устойчива к кривым рукам разработчиков. Например я на личном опыте убедился, что MSSQL к сожалению в случае "дикой" проектировки БД валиться и довольно неплохо. История простая - меня попросили в качестве эксперта посмотреть и оценить, каковы шансы перевести БД MSSQL на другую платформу, мотивируя это нестабильной и тормознутой работой MSSQL. Посмотрев на это "чудо", я порекомендовал прекратить обвинять MSSQL во всех смертных грехах и пересмотреть свои взгляды на проектирование БД и реализацию логики ее работы. Сейчас вот пишу документ-обоснование, доказывающий, что MSSQL тут совсем не причем и смена платформы кроме затраты времени и финансов ни чего больше не принесет. P.S. А вообще то конечно в этом плане MSSQL немного меня удивил - какие бы не были в БД применены некорректные решения и пусть все бы тормозило, но вот валиться СУБД не должно ни в коем случае, в любом случае надежность работы и хранения данных в таких системах должна быть превыше всего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2004, 16:53 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
к вопросу о стабильности базы :) Я пару раз наблюдал ситуацию, когда клиентское приложение на VB умудрялось записать в таблице БД некое значение, после которого все становилось раком - ни один селект, затрагивающий определенную странцу данных не выполнялся - сервер "отстреливал" соединение. Лечилось только DBCC CHECKDB. Насчет кривых рук - согласен. Пример. Таблица сделок разных типов (Forex, Fixed Income и т.п.) - ширина 220 полей, из них - порядка 40 полей обозначены как UDF_001 - UDF_040, в которых хранится всякая фигня (поля типа varchar) и мало кто знает, что это за информация. PS. Сервер 7.0 :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2004, 20:20 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Чтобы Oracle валился от кривого приложения - я такого не встречал. А проблемы с производительностью практически гарантированы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 10:19 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Давайте еще посоревнуемся у кого больше индексов на одну таблицу...) у меня - 20 (двадцать)...(но автор не я...))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 11:31 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Если в эту таблицу редко пишут но часто читают, то 20 индексов может быть нормальным - все зависит от ее использования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 11:34 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
как раз нет...и пишут хорошо, и читают замечательно... 6 индексов - вообще не используется... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 11:44 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Подумаешь 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.01.2004, 12:21 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
а еще меня прикалывает когда справочник содержит в качестве ключевого поля значение NULL, очень прикалывает, когда имена таблиц : TABLE1, TABLE2 ... TABLE153...) Прикалывает, когда на поля, в которых 1-2 допустимых значения (пол-мужской-женский) заводится отдельная таблица: select * from TABLES123 INDEXMAINS123 SEX --------------- --------------- NULL Не определено 1 M 2 Ж ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 13:15 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Пол = NULL - это сильно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 13:48 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Конечно отдельная таблица для пола это изврат, но ПОЛ=NULL вполне реально. писал БД для судебно-медицинских лабораторий, так так это вполне вероятно когда заносят информацию об останках и определить пол не возможно - тогда он действительно NULL :( Главное, чтобы в ДНК ошибки не было ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 14:23 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
NULL<> NULL - вот в чем вопрос... По NULL таблицы не объеинить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 14:55 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
А почему кстати отдельная таблица для пола изврат ? Во первых клиентское приложение в виде DBLookup может спрашивать пол без его жесткого вшития в код, во вторых если БД интернациональная, то м/ж не очень катит с точки зрения других языков. Плюс возможны варианты хранения краткого/полного наименования, падежей и т.д. Опять же я считаю смотря для каких задач это изврат/не изврат. Но вот в Primary Key делать NULL - это однозначный изврат. Слава богу, такое только на Access возможно, обломали радость велосипедистам горе-проектировщикам :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 15:08 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Можно придумать кучу таблиц, где имеется все одно-два допустимых значения. примеры: Муж/Жен, Резидент/нерезидент,Да/Нет,Физ.лицо/Юр.лицо... Короче все это перечислять можно долго. Для таких вещей проще прменять chech constraint AtField (field in 'Yes','No'). ИМХО нефиг тратить ресурсы на foreign key и его поддержку. Ей богу так - эффективней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 16:33 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
автор Короче все это перечислять можно долго. Для таких вещей проще прменять chech constraint AtField (field in 'Yes','No'). ИМХО нефиг тратить ресурсы на foreign key и его поддержку. Ей богу так - эффективней. Эффективней (и правильней) в таких случаях применять Rules. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 17:04 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
а где хранить языковые варианты? правда, справочник полов и их названий на разных языках просто может быть не привязан форин кеем? все равно их только два. //а кстати, жизнь прекатсна и отвратительна, полов теперь больше чем два! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 17:15 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Языковые варианты....)) Давайте будет так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. нравицца? Честно говоря мне такой гемор не нужен. Если приспичит, но в приложении обработаю... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 17:36 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 17:48 |
|
||
|
эти кривые базы данных...
|
|||
|---|---|---|---|
|
#18+
Угу, можно и падежи, и сокращения, и языки... и довести все до абсурда...)) Еще и нормализовать все до опуперия, построить индексы по всем полям на все случаи жизни... А потом думать, а чего так все медленно ворочаецца?... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2004, 17:53 |
|
||
|
|

start [/forum/topic.php?fid=35&fpage=51&tid=1554185]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
2ms |
| others: | 209ms |
| total: | 357ms |

| 0 / 0 |
