Ну кто так проектирует БД...

← →
Megabyte © (2006-05-10 14:22) [0]

Устроился на новую работу в тур.фирму, цитирую, "специалистом по SQL".
На фирме до меня не было ни одного собственного программера. Никто ничего не рюхает. Даже вакансию не могли нормально написать. Долго выбивал наводящими вопросами, что за СУБД и на чем написан клиент(правда, мне не придется с ним возиться), чего они от меня вообще хотят.
От меня больше требуется тех.поддержка, администрирование БД. Чтобы все это работало, а если не работает, то разобрать, в чем проблема(сеть, БД, клиент). Если проблема в клиенте, то обосновать заявку на исправление ошибки на клиенте(хотя хз, как я разберусь, в чем проблема на клиенте, без исходников). БД и клиент поставляются стронней фирмой.

Так вот, увидел я БД. УЖОС!!! Я себя не считаю мегарюхом в проектировании БД. БД большая - 276 таблиц.
Но нафига делать View 1515, в пять раз больше, чем таблиц???
Половина таблиц не нормализована: нет первичных ключей!!!
Еще изврат: два десятка таблиц с одним полем и одной записью: норер какого-то ключа. Видно не судьба это все в одной таблице написать...

А ведь, я так понимаю, за каждое обновление сторонняя фирма получает бабло. По ходу они просто за дурачков держат фирму, в кот. я работаю теперь.

p.s. Ну не думал я, что стронняя программерская контора, занимающаяся разработкой таких больших проектов, создает БД без элементарных правил проектирования!!!

p.s. Вот во всей этой куче мне надо будет разобраться. Опыт, конечно, полезный. Только во всем придется разбираться самому...

← →
Sergey13 © (2006-05-10 14:30) [1]

>А ведь, я так понимаю, за каждое обновление сторонняя фирма получает бабло.
Глупо было бы ожидать обратного. 8-)

>По ходу они просто за дурачков держат фирму, в кот. я работаю теперь.
Только не говори это никому - ни работодателям ни разработчикам. 8-)

← →
Некто_ (2006-05-10 14:37) [2]

А может клиент и не трогает все таблицы, а юзает пару десятков нормализованных.

← →
Гаврила © (2006-05-10 15:04) [3]

> Только не говори это никому - ни работодателям ни
> разработчикам. 8-)

Поздно. Уже сказал :-)

← →
Плохиш © (2006-05-10 15:07) [4]

Как всегда, у пионэра, что не понятно, то "УЖОС!!!"

← →
Anatoly Podgoretsky © (2006-05-10 15:45) [5]

Гаврила © (10.05.06 15:04) [3]
Ну тогда пусть начинает искать новое место работы.

← →
Некто_ (2006-05-10 16:06) [6]

> Как всегда, у пионэра, что не понятно, то "УЖОС!!!"

Точно =))) Раньше такое за собой замечал, теперь более сносно к таким вещам отношусь.

← →
Megabyte © (2006-05-10 16:27) [7]

Да ну вас, приколисты. %)
Никуда я не пойду, ведь только устроился.

Фишка только в том, что нельзя предъявить претензии той фирме, ведь база вроде пока работает без нормализации таблиц. А претензии можно высказать, когда уже проблемы будут. :/

← →
Sergey13 © (2006-05-10 16:36) [8]

2[7] Megabyte © (10.05.06 16:27)
>Фишка только в том, что нельзя предъявить претензии той фирме, ведь база вроде пока работает без нормализации таблиц.
Ну дык логично. Работает ведь. А совершенству нет предела.

>А претензии можно высказать, когда уже проблемы будут. :/
Все ищут ответа - где главный идеал
Пока ответа нету - копите капитал.
(с) Пестня

← →
Jeer © (2006-05-10 16:45) [9]

Megabyte © (10.05.06 16:27) [7]

Я тебе по секрету скажу - база вполне может и будет работать без нормализации.

← →
Sergey13 © (2006-05-10 16:46) [10]

2[9] Jeer © (10.05.06 16:45)
Иногда даже быстрее. 8-)

← →
Desdechado © (2006-05-10 17:32) [11]

добавлю, что:
1. "Половина таблиц не нормализована: нет первичных ключей" - там могут быть внешние или просто уникальные :))
2. "два десятка таблиц с одним полем и одной записью" - не факт, что это неправильно. В серийном софте у других юзеров (которые пользуются какими-то нюансами) могут быть заполнены таблицы по-другому
3. много вьюх - не страшно
4. много таблиц - тоже нормально

единственно, не представляя предметной области, несколько удивлен количеством таблиц
на первый взгляд за 100 выползти не должны были

← →
Jeer © (2006-05-10 17:38) [12]

Desdechado © (10.05.06 17:32) [11]

> на первый взгляд за 100 выползти не должны были

Могут быть бросовые - делали update, данные переносили в модифицированные таблицы, с старые не удаляли. Запросто.
По статистике можно глядеть.

← →
Desdechado © (2006-05-10 17:42) [13]

> данные переносили в модифицированные таблицы, старые не удаляли
и такое бывает, но это уже разгильдяйство

← →
Sergey Masloff (2006-05-10 20:34) [14]

Что вьюх больше чем таблиц - так это вообще нормально.
Вот что смущает что первичных ключей нет. Остальное вроде нормально. Ну еще может таблиц многовато именно для данной предметной области - я ее более-менее представляю и интегрировался с несколькими известными программами и схемы видел. Но фиг его знает как там на самом деле.

← →
Игорь Шевченко © (2006-05-10 21:46) [15]

Sergey Masloff (10.05.06 20:34) [14]

> Вот что смущает что первичных ключей нет.

А это они наверное здешнюю диспуссию (дискут) не читали...К тому же сказать add constraint никогда не поздно. Меня больше удивляет другое - приходит вот такое на фирму и начинает - то у них не так, это у них не так. Добро бы его ведущим консультантом по рефакторингу приглашали, и то неэтично бы было. Давить таких в зародыше вообще-то.

← →
kaif © (2006-05-10 22:07) [16]

2 Megabyte ©
А какие-нибудь ключи (уникальные индексы) в тех таблицах имеются?
Если да, то ты неправ. Если нет - то ты прав.
Кол-во вьюх может быть большим. Вьюхи место не занимают.
Другое дело, что непонятно, зачем столько вьюх может понадобиться в правильно организованной базе. А какого рода вьюхи?

2 Desdechado ©
Внешние ключи не имеют отношения к вопросу.
Если отсуствует первичный ключ или альтернативный ключ (уникальный индекс), то это плохо. Плохо по простой причине: как, например, Вы с помощью SQL удалите одну отдельную строку, если в таблице несколько совершенно таких же точно строк?

← →
Игорь Шевченко © (2006-05-10 22:50) [17]

> Плохо по простой причине: как, например, Вы с помощью SQL
> удалите одну отдельную строку, если в таблице несколько
> совершенно таких же точно строк?

А зачем их удалять ?

← →
Sergey Masloff (2006-05-11 06:55) [18]

Игорь Шевченко © (10.05.06 21:46) [15]
>А это они наверное здешнюю диспуссию (дискут) не читали...
Или я не в теме или дискуссия была о другом. Я имел в виду отсутствие первичного ключа как такового (constraint primary key) а дискуссия была о естественные vs суррогатные? В данном случае все равно какой ключ суррогатный или нет.
А вот если ключа нет вообще то это может вызвать некие скрытые действия. Тот же Interbase без ключа никак не может и в случае отсутствия оного на каждый селект будет строить ключ по всем полям таблицы а потом убивать его после селекта. И так каждый раз. А оно надо?

← →
Sergey13 © (2006-05-11 10:27) [19]

2 [16] kaif © (10.05.06 22:07)
>как, например, Вы с помощью SQL удалите одну отдельную строку, если в таблице несколько совершенно таких же точно строк?

Иногда конкретная строка и не интересует никого, а интересуют группы, например на дату. Удалить записи по дате - нет проблем.

← →
Игорь Шевченко © (2006-05-11 10:37) [20]

Sergey Masloff (11.05.06 06:55) [18]

> Тот же Interbase без ключа никак не может и в случае отсутствия
> оного на каждый селект будет строить ключ по всем полям
> таблицы а потом убивать его после селекта

Источник в студию

← →
Val © (2006-05-11 11:06) [21]

>[16] kaif © (10.05.06 22:07)

> зачем столько вьюх может понадобиться в правильно организованной
> базе.

возможно, для сложной нарезки прав доступа

← →
Desdechado © (2006-05-11 11:31) [22]

kaif © (10.05.06 22:07) [16]
> Внешние ключи не имеют отношения к вопросу.
Читаем внимательно [0]:
Половина таблиц не нормализована: нет первичных ключей!!!
И только потом мой пост. И понимаем, что не обязана КАЖДАЯ таблица иметь первичный ключ, потому как она может быть всего лишь дополнением таблицы с первичным ключом, будучи связанной с ней через внешний ключ.
Типичный пример - кросс-таблицы. Там, правда, обычно ставят уникальность. Но есть и другие варианты, когда в таблице достаточно иметь внешний ключ без первичных и уникальных.

← →
kaif © (2006-05-11 15:15) [23]

2 Desdechado © (11.05.06 11:31) [22]
Я считаю Вас хорошим специалистом в SQL (а их не так много) и потому ругаться не хочу. Давайте попробуем разобраться.
Приведите, пожалуйста, пример таблицы с внешним ключом (в применении к какой-либо предметной области), в которой не обязательно иметь первичный ключ или иную уникальность. Хорошо бы такой пример, который оправдал бы большое количество таких таблиц в базе (половину).
И поясните термин "всего лишь дополнение таблицы с первичным ключом".
С уважением.

← →
kaif © (2006-05-11 15:21) [24]

Sergey13 © (11.05.06 10:27) [19]
2 [16] kaif © (10.05.06 22:07)
>как, например, Вы с помощью SQL удалите одну отдельную строку, если в таблице несколько совершенно таких же точно строк?

Иногда конкретная строка и не интересует никого, а интересуют группы, например на дату. Удалить записи по дате - нет проблем.

Разумеется, это те ситуации, в которых и редактирование отдельной строки не требуется. То есть случай, когда нужно иметь дело просто с множеством. Причем таким множеством, в котором вероятное наличие дубликата исключено каким-то внешним способом или вообще не играет никакой роли.
Любопытно, какого рода информация в работе турагентства может храниться подобным образом?

← →
Sergey13 © (2006-05-11 15:32) [25]

2[24] kaif © (11.05.06 15:21)
>Любопытно, какого рода информация в работе турагентства может храниться подобным образом?
Например меню ресторана в отеле проживания. Кофе может стоять везде. 8-)
Погода за последний месяц. Может быть сколько угодно показателей за день.
Отзывы туристов о проведенном туре.
Да мало ли можно придумать - я не шибко представляю кухню турагенства. 8-)

← →
Petr V. Abramov © (2006-05-11 15:36) [26]

> Sergey13 © (11.05.06 15:32) [25]
> Погода за последний месяц. Может быть сколько угодно показателей за день.
Оказалось, "вот этот" показатель (из числа тех, которых несколько за день) вбит неверно и его надо удалить. Ваш SQL-запрос?

← →
Jeer © (2006-05-11 15:42) [27]

Petr V. Abramov © (11.05.06 15:36) [26]

А напишем новый скрипт (update-приложение), перегоним в новую таблицу - вот откуда так много таблиц:))

← →
Sergey13 © (2006-05-11 15:43) [28]

2[26] Petr V. Abramov © (11.05.06 15:36)
> его надо удалить.
А смысл?

>Ваш SQL-запрос?
Delete from POGODA where rowid=:rowid
8-)

2 [29] Petr V. Abramov © (11.05.06 15:48)
> а без rowid?
Потом еще без SQL попросишь. Ну нафик. 8-)

Смысл то был, что могут существовать таблицы, где каждая конкретная запись не интересна. Какой нибудь лог устройсва для подсчета среднесуточного значения. Такого быть не может? Может, ИМХО.

Я сам ПК везде леплю, и не говорю, что система из сабжа сильно хороша. Но и говорить, что сильно плоха - тоже не возьмусь. Вот и треплюсь просто. 8-)

> Sergey13 © (11.05.06 15:54) [30]
> Потом еще без SQL попросишь. Ну нафик. 8-)
Без SQL не попрошу, но засчитано :)

> Смысл то был, что могут существовать таблицы
могут. А в количестве половины всех существующих - не имеют права. Скорее всего, система изначально на DBF-никах была, и ее тупо в какой-нить SQL-сервер влили. И теперь гордо говорят, что система не зависит от СУБД :)

2[31] Petr V. Abramov © (11.05.06 15:59)
> Без SQL не попрошу
В DOA можно и "без SQL" (именно в кавычках! 8-). Они опираются именно на ROWID, а не на ПК. Наверное аналог ROWID есть во многих СУБД. И для работы с одной таблицей они вполне применимы. Связи на них не построишь, а остальное - легко.

> Скорее всего, система изначально на DBF-никах была, и ее тупо в какой-нить SQL-сервер влили.
Может и так. Даже скорее всего. Однако от автора вроде так и не было ответа на вопрос об уникальных ключах. Может они есть, только ПК не обозваны.

> Sergey13 © (11.05.06 16:10) [32]
> Наверное аналог ROWID есть во многих СУБД
нету. по крайней мере в FB и MSSQL (старом)

> И для работы с одной таблицей они вполне применимы
и то пока rowid не уплывет. Редко-редко, но вполне реально.

2[33] Petr V. Abramov © (11.05.06 16:16)
> нету. по крайней мере в FB и MSSQL (старом)
В ФБ вроде есть DB_KEY.

> и то пока rowid не уплывет. Редко-редко, но вполне реально.
Я не думаю, что узер работает во время экспорта/импорта с импортируемыми записями или админ что-то серьезное делает во время работы.

> Sergey13 © (11.05.06 16:23) [34]
select db_key from t1 - не понимает. Хотя слово для IBExpert знакомое. Разбираться, если честно, лениво :)

я ж не говорю, что они все время плавают и что пльзоваться ими нельзя.

>> нету. по крайней мере в FB и MSSQL (старом)
> В ФБ вроде есть DB_KEY.
в MSSQL тоже есть, только внутренний идентификатор.
во всяком случае при пробежке по задекларированному курсору по абсолютно идентичным записям (все видимые значения одинаковы, без ключа) можно менять значения у одной записи, и оно не сбивается! меняет именно по одной. ничем другим как внутренним индентификатором записи по которому идет разделение обьяснить это я не могу...
насколько действительно для старых версий ... х.з.

> админ что-то серьезное делает во время работы.
может происходить вполне штатное
alter table ... move tablespace
alter table ... split partition

хоть и редко, но глазки у юзера будут большие

2[38] Petr V. Abramov © (11.05.06 16:41)
> хоть и редко, но глазки у юзера будут большие
А с чего бы? Ну не изменятся данные или не сотрутся. Ну и что. Он попробует еще разок - и все пройдет как надо. 8-)

> А с чего бы? Ну не изменятся данные или не сотрутся. Ну и что.
По сравнению с ужасной демографией - фигня :) А для человека - маленькая трагедия :)

Ну кто так проектирует БД... Найти похожие ветки