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

← →
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-)

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

> Sergey13 © (11.05.06 15:43) [28]
отвертелся :)
а без rowid?

← →
Sergey13 © (2006-05-11 15:54) [30]

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

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

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

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

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

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

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

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

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

← →
Petr V. Abramov © (2006-05-11 16:16) [33]

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

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

← →
Sergey13 © (2006-05-11 16:23) [34]

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

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

← →
Petr V. Abramov © (2006-05-11 16:35) [35]

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

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

← →
Sergey13 © (2006-05-11 16:38) [36]

2[35] Petr V. Abramov © (11.05.06 16:35)
> select db_key from t1 - не понимает
select RDB$db_key from t1

← →
sniknik © (2006-05-11 16:40) [37]

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

← →
Petr V. Abramov © (2006-05-11 16:41) [38]

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

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

← →
Sergey13 © (2006-05-11 16:45) [39]

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

← →
Petr V. Abramov © (2006-05-11 16:50) [40]

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

← →
Sergey13 © (2006-05-11 16:54) [41]

2[40] Petr V. Abramov © (11.05.06 16:50)
> По сравнению с ужасной демографией - фигня :) А для человека - маленькая трагедия :)
8-)
Трагедией бы было если бы стерлось или поменялось что-то отличное от нужного. А так - просто маленький облом. Можно списать на "глюкавость винды". 8-)

← →
Petr V. Abramov © (2006-05-11 16:56) [42]

> Трагедией бы было если бы стерлось или поменялось что-то отличное от нужного.
Это уже пахнет трагедией разработчика с админом :)

← →
Desdechado © (2006-05-11 19:48) [43]

kaif © (11.05.06 15:15) [23]
> Я считаю Вас хорошим специалистом в SQL
"А в сердце лесть всегда отыщет уголок" (с) Крылов
:))

> Приведите, пожалуйста, пример таблицы с внешним ключом,
> в которой не обязательно иметь первичный ключ или иную уникальность.
Например, таблица "показатели", на которую ссылается таблица "результаты измерений". Можно туда втулить уникальность на комбинацию полей "показатель - дата", но смысла нет, ибо даты до миллисекунд.
Собственно, выше похожий пример приводили. Если это накопительная таблица, в которой никогда не удаляются и не редактируются записи, то такое вполне оправдано. Однако можно удалять пачками по диапазону дат или по показателям.

> Хорошо бы такой пример, который оправдал бы большое количество
> таких таблиц в базе (половину).
Кстати, протоколы изменения данных в таблицах могут быть такими - тоже дата и состояние записи на момент изменения. И ссылка на ключ изменяемой таблицы. А если протоколируется много таблиц, то и протоколов много.
(кстати говоря, я предпочитаю протоколирование немного другим способом, но описанный выше - вполне естественный подход).

> поясните термин "всего лишь дополнение таблицы с первичным ключом"
Например, часть атрибутов некоторой сущности хранится не в основной таблице, а, в силу редкого использования, в отдельной со ссылкой на главную. Вот и получается дополнение. Причем часто без уникальных ключей в дополнительной таблице.

← →
kaif © (2006-05-11 20:59) [44]

2 Desdechado © (11.05.06 19:48) [43]
:)
Ну что же. Вы меня убедили, пожалуй. По крайней мере в отношении логов.

Остается понять, что такого может быть в таблицах турагенства.
Но это вопрос уже к автору сабжа. Хотелось бы чтобы он прояснил.
Иначе у публики сложилось впечатление, что он поверхностно подошел к вопросу вникания в то, что сделано до него.

Однако мне интуиция подсказывает (да и опыт тоже), что если у турагенства имеется сотня таблиц без первичных или каких-либо альтернативных ключей, то вряд ли это показания каких-то датчиков, а уж тем более меню обедов.
:)

← →
VictorT © (2006-05-12 11:00) [45]

Вот, имею сейчас дело с БД, в которой отсутствуют первичные ключи, и какие-либо индексы вообще, и практически все поля varchar :(

← →
REA (2006-05-12 11:07) [46]

2Megabyte

Поздравляю: вы тот самый негр, который будет долго и неблагодарно разгребать чужое эээ творчество (а зачем платить зарплату? - оно же и раньше работало). Постарайся расслабиться и начинать подыскивать новую работу.

← →
REA (2006-05-12 11:10) [47]

PS: хорошим туристическим движком + Web можно успешно торговать, если он у тебя получится. Их по пальцам пересчитать, а контор сотни, если не тысячи.

← →
Megabyte © (2006-05-12 12:31) [48]

> REA (12.05.06 11:07) [46]
> 2MegabyteПоздравляю: вы тот самый негр, который будет долго
> и неблагодарно разгребать чужое эээ творчество (а зачем
> платить зарплату? - оно же и раньше работало). Постарайся
> расслабиться и начинать подыскивать новую работу.

Не гони. %) Имхо, полезный опыт, тем более, если смогу разобраться. ;)

По поводу кол-ва таблиц: по ходу все таки там большая часть таблиц не юзается, для старых версий. Как кто-то тут сказал, банальное разгильдяйство.

По поводу вьюх: там несколько групп вьюх с одинаковым названием, но для разных юзеров! Т.е. создавали новую вьюху для каждого юзера. И, наверное, вьюхи для пользователей, кот. уже не работают, тоже ничего не удалили.

Насчет других ключей в таблицах: уникальных, внешних. Я мало работал с Enterprise Manager"ом(в IB_Experte нашел бы сразу). Где там посмотреть и как наличие суррогатных и уникальных ключей?

← →
Desdechado © (2006-05-12 12:51) [49]

Megabyte © (12.05.06 12:31) [48]
> Долго выбивал наводящими вопросами, что за СУБД и на чем написан клиент
так поделись с нами, тогда можно будет сказать

> Где там посмотреть и как наличие суррогатных и уникальных ключей

← →
kaif © (2006-05-12 13:00) [50]

Видно MS SQL, судя по тому, что говорит автор.

← →
Sergey13 © (2006-05-12 13:05) [51]

2[50] kaif © (12.05.06 13:00)
А я про Оракл подумал. 8-)

← →
Desdechado © (2006-05-12 13:08) [52]

Sergey13 © (12.05.06 13:05) [51]
и я, про OEMC

← →
kaif © (2006-05-12 13:13) [53]

Ну в Oracle Enterprise Manager Console автор нашел бы все ключи довольно быстро.

← →
Megabyte © (2006-05-12 14:19) [54]

> Desdechado © (12.05.06 12:51) [49]
> Megabyte © (12.05.06 12:31) [48]> Долго выбивал наводящими
> вопросами, что за СУБД и на чем написан клиенттак поделись
> с нами, тогда можно будет сказать

Ой, простите. Забыл совсем. %)
Конечно MSSQL. Юзаю,соответственно, SQL Server Enterprise Manager.

Клиент написан, со слов начальника техотдела, где я работаю, на C#. Но мне с ним(с клиентом) работать не придется.

← →
kaif © (2006-05-12 14:33) [55]

Иногда отвечая на вопросы в форуме "Базы данных" поневоле станешь телепатом :)

← →
Сергей М. © (2006-05-12 15:58) [56]

> Megabyte © (10.05.06 14:22)

> в тур.фирму

А контора SPOLINE при этом как-то фигурирует ?

Нет.

Если будет фигурировать хоть как-то фигурировать (http://www.spoline.ru/) - беги от них как от прокаженных.

> Megabyte © (12.05.06 14:19) [54]

Запусти SQL Profiler в рабочее время на часок, запиши лог и проанализируй на использование таблиц/вьюх. Неиспользованные перегони в другую базу на всякий случай. Если чо - вернешь.

> AlexWlad © (12.05.06 18:12) [59]
> > Megabyte © (12.05.06 14:19) [54]Запусти SQL Profiler
> в рабочее время на часок, запиши лог и проанализируй на
> использование таблиц/вьюх. Неиспользованные перегони в другую
> базу на всякий случай. Если чо - вернешь.

м.б. По крайней мере это я сделаю для того, чтобы понять, какие таблицы юзаются. :)

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

Очень похоже на объектную БД

> А претензии можно высказать, когда уже проблемы будут

Можно и сейчас. вида "отчет ХХХ строится полчаса вместо минуты, пользователю неудобно". А начальству - "Эти козлы налажали там то и там то. Если бы они сделали малость по правильному другому то скрорость работы приложения была бы выше в ХХХ раз следовательно скорость и качество обслуживания клиентов следовательно ты шеф бабла больше огребешь на УУУ р в месяц"

> [15] Игорь Шевченко © (10.05.06 21:46)
Давить таких в зародыше вообще-то

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

2[62] paul_k © (16.05.06 10:10)
Я бы поостерегся так говорить, особенно не зная ДОСКОНАЛЬНО что как и почему так работает. Иначе можно налететь на АРГУМЕНТИРОВАННЫЙ ответ, что "сам козел". 8-)

>Sergey13 © (16.05.06 10:26) [63]
>Иначе можно налететь на АРГУМЕНТИРОВАННЫЙ ответ, что "сам козел". 8-)

И не говори, кум ;)
Помню, как я плевался, впервые заглянув в "потроха" абсолютно незнакомой БД (акцес), оказавшейся объектной. И как потом восторгался людьми, ее разработавшими. После того, как съездил к ним и поговорил. Они оаказались куда "продвинутее" меня ;))

> Sergey13 © (16.05.06 10:26) [63]
> 2[62] paul_k © (16.05.06 10:10)Я бы поостерегся так говорить,
> особенно не зная ДОСКОНАЛЬНО что как и почему так работает.
> Иначе можно налететь на АРГУМЕНТИРОВАННЫЙ ответ, что "сам
> козел". 8-)

Когда проанализирую все логи, то с удовольствием пообщаюсь с разработчиками. ;) Но ни на кого наезжать сразу не буду, что мне делать нечего. Только как мне сказал начальник нашего отдела, там с отдельмыми пользователями общаются неохотно.

> paul_k © (16.05.06 10:10) [62]
> Чел за фирму свою переживаеть хочеть чтоб усе работало
> быстро и без сбоев.

Ну да. :) Просто я хочу разобраться еще, если это сделано так, то почему!

з.ы. Во многих запросах встречаю такую конструкцию: select...from... where 1=2???
Это что, такая фишка в MSSQL? Как это вообще может быть верно?

> [63] Sergey13 © (16.05.06 10:26)

> [64] MsGuns © (16.05.06 10:34)

Странно, но мы с вами об одном и томже, просто разными словами.
Я о том, что не разобравшись полностью в том как устроена программка не возможно аргументировать позицию ни относительно "наезда на разработчика" ни относительно "мотивации необходимости наезда шефу"

> [65] Megabyte © (16.05.06 11:25)
> Только как мне сказал начальник нашего отдела, там с отдельмыми
> пользователями общаются неохотно

Ну это зависит от суммы техподдержки в месяц. И риска потерять оную:)

> select...from... where 1=2???

Пустой запрос буде ибо условие 1=2 не выполнится никогда. Встречал подобные конструкции там где народ кодогенераторами и шаблонами различными пользуется. Скоропалительный вывод - у разработсика собственное средство разработки.

> Пустой запрос буде ибо условие 1=2 не выполнится никогда.
> Встречал подобные конструкции там где народ кодогенераторами
> и шаблонами различными пользуется. Скоропалительный вывод
> - у разработсика собственное средство разработки.

Встречается уж слишком часто она.

2[65] Megabyte © (16.05.06 11:25)
>з.ы. Во многих запросах встречаю такую конструкцию: select...from... where 1=2???
Возможно, таким образом запрашивают структуру полей таблицы (зпроса).

> Возможно, таким образом запрашивают структуру полей таблицы
> (зпроса).

Хм. Интересно.

Скорее, на клиенте нужен пустой НД с заданной структурой

← →
Третий (2006-05-16 15:36) [72]

Megabyte © (16.05.06 11:25) [65]
з.ы. Во многих запросах встречаю такую конструкцию: select...from... where 1=2???

Либо, для добавления новой записи в модальном окне. При открытии окна делается запрос и сразу DataSet.insert.

2[71] Petr V. Abramov © (16.05.06 15:33)
Может и так. Просто я встречал в форумах рассказы про динамическое постоение интерфейса - там таким образом тягали болванку набора данных.

Обнаружил еще одну интересную вещь. Есть 10 таблиц-справочников.
Все 1500 вьюх - это точная(!) копия этих справочников, только сделанная для каждого пользователя.
Наверное, это у них таким образом организован совместный доступ к справочной информации. %)))

← →
Guest 111 (2006-05-16 16:41) [76]

> Megabyte © (16.05.06 16:31) [74]

where 1=2

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

> Все 1500 вьюх - это точная(!) копия этих справочников, только
> сделанная для каждого пользователя.
> Наверное, это у них таким образом организован совместный
> доступ к справочной информации. %)))

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

Я не знаю этой системы, но ярлыки сразу вешать не стоит :)

> Игорь Шевченко © (16.05.06 16:35) [75]
> Megabyte © (16.05.06 16:31) [74] Тебе не кажется, что
> твои повествования выглядят неэтично ? Просто интересно.

Неэтично по отношению к чему/кому? Это разве кого-то здесь должно задевать??? Решительно вас не понимаю...
Я только рассказываю, что вижу. М.б. кто-нибудь мне подскажет что из собственного опыта.

Megabyte © (16.05.06 16:42) [77]

> М.б. кто-нибудь мне подскажет что из собственного опыта

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

Megabyte © (16.05.06 16:42) [77]

Успеешь вещички собрать ?

Присоединяюсь к мнению Шевченко, что обсуждение потрохов коммерческого продукта очень сильно напоминает публичный реинжиниринг.

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