|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
ant[Ares] пишет: > Есть список "подразделений", у каждого есть внутренний номер. И они > хотят чтобы этот внутренний номер был "как бы" первичным ключом, но > чтобы он генерировался не БД, а вводился вручную и при этом не еще раз. ДАйте им их любимые ключи, и все, в любом количестве. В таблице может быть несколько альтернативных ключей, это нормально. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2008, 10:28 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
MasterZiv ant[Ares] пишет: > Есть список "подразделений", у каждого есть внутренний номер. И они > хотят чтобы этот внутренний номер был "как бы" первичным ключом, но > чтобы он генерировался не БД, а вводился вручную и при этом не > проверялся... т. е. возможно дублирование. Вот пример объяснения: Как же Ну так создайте им это поле их, шифр подразделения, без UNIQUE на него (а лучше бы с , не помешает), И все. А внутри сами пользуйтесь своими PK - identity или как вам там удобно. Это - вполне нормально с любых точек зрения. Posted via ActualForum NNTP Server 1.4 Знаете в чем трагизм? ОНИ ЭТОГО НЕ ХОТЯТ!!! Мы пришли к ним со структурой БД... они посомтрели и говорят: "Да типа все клево, НО тогда сделайте так чтобы ВАШ id СОВПАДАЛ С НАШИМ КОДОМ!!!" ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2008, 10:37 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
GarryLСудя по топику в системе есть небольшой(или большой?) косяк в архитектуре и непонимание бизнес процессов архитектором. :) Это стоит проверить в первую очередь. Обязательно проверим. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2008, 10:51 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
ant[Ares] пишет: > Знаете в чем трагизм? ОНИ ЭТОГО НЕ ХОТЯТ!!! > Мы пришли к ним со структурой БД... они посомтрели и говорят: "Да типа > все клево, НО тогда сделайте так чтобы ВАШ id СОВПАДАЛ С НАШИМ КОДОМ!!!" Скажите, что ВАМ он нужнен для внутренних целей. В руководстве по MSSQL Server современному вообще чуть ли не требованием прописано (на самом деле рекомендация по повышению производительности), чтобы во всех таблицах был бы PK по короткому (целочисленному) ключу типа identity. Ткните их туда носом, скажите, что это надо вам, для нормальной работы БД и приложения, а то, что хотят они, вы обеспечите, при этом ваши PK никому не помешают. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2008, 11:06 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
ant[Ares] пишет: > Судя по топику в системе есть небольшой(или большой?) косяк в > архитектуре и непонимание бизнес процессов архитектором. :) > Это стоит проверить в первую очередь. > Обязательно проверим. Да не, вряд ли ... Требование наличия PK косяком никак называть нельзя. Требование наличия идентификатора в терминах пользователя может вы и пропустили. Ну так добавите сейчас. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2008, 11:08 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
MasterZiv Никак не убедить пишет: > Да при чем тут нытье то... Я же не пожалеть меня прошу. > Хочется узнать как можно убедить человека в том что он не прав в данном > случае. Да никак не убедишь человека, если он не понимает. Можно конечно прочитать теоретическую лекцию, попросить почитать работы Кодда и Дейта, но, как правило, люди понимающие уже это сделали давно, а непонимающие - уже никогда не сделают. Posted via ActualForum NNTP Server 1.4[/quot] теоретическую лекцию по мотивам Кодда и Дейта будете читать перед программистами, там вас слушать никто не будет когда Вы задаете вопрос заказчику они ведь не читают вам выдерки из своих тысячестраничных положений о документообороте как поступить вам уже сказали, у вас наверняка есть чел, который работает с людьми из этой госконторы, тот кто договор согласовывал, откат "пилил" и отдавал....вот этот человек пусть доведет до людей из госконторы (до тех, кто по этому проекту реально что-то решает и в чем-то заинтересован) грядущие проблемы....проблемы должны быть описаны простым и понятным языком, описание проблемы можете протестировать, скажем, на своей маме (если она не айтишник) в конкретном случае (проблемы, которые выползут при отказе от первичных ключей) - это текст на половину страницы ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2008, 11:46 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
MasterZiv Да не, вряд ли ... Требование наличия PK косяком никак называть нельзя. Требование наличия идентификатора в терминах пользователя может вы и пропустили. Ну так добавите сейчас. Posted via ActualForum NNTP Server 1.4 Я просто в том сообщении не стал конкретизировать. Речь вел про ранее упомянутый бизнес процесс: >> Тогда может иметь место ситуация, что этот самый код подразделения присваивается сначала >>НА БУМАГЕ (руководителем или ОК) по каким-то их бизнес-алгоритмам, от которых они не хотят >>отступать. Из моей практики сделал такой вывод. Возможность наличия двух разных ключей (ЕК и СК) у сущности людьми без образования в сфере БД просто не воспринимается. увы. Если этот человек большой начальник, то проблема иногда неразрешима. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2008, 12:07 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
1. Приведите сравнение между первичными ключами и фундаментом здания, т.е. отсутствие первого, аналогично отсутствию второго, если заказчика устраивает, нужно этот факт задокументировать, чтобы когда все обрушится было к чему аппелировать. 2. сделайте им вьюхи для их запросов ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2008, 12:13 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
1) Как уже написали, любые изменения и дополнения в ТЗ должны быть оформлены письменно. Причем вы вправе требовать аргументацию к любым требованиям, в том числе и "убрать ключи". 2) На самом деле, изначальный подход "девушки которым не место за компьютером", "Женщины и программирование совместимы очень редко" - неверен. Потому их безусловно дурацкое требование совсем не означает что никакой проблемы нет в принципе. И возможно, они просто не могут обьяснить, что им нужно на самом деле. Nobody faults but mine... (LZ) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2008, 12:15 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
Мне кажется, автор темы не привел достаточно развёрнутых технических пояснений и не осветил бизнес-правила организации. Так что обсуждение ведется практичесик вслепую. Я свою версию озвучил, мне кажется, что она близка к истине. А вообще, может быть что угодно. Но интуиция мне подсказывает, что "девушки-плохие-программистки" не на пустом месте выдвигают требования. Другое дело, что должно перевесить: их требования или требования разработчика? А для того, чтобы взвесить и принять решение, надо больше информации. Вот так. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2008, 12:38 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
[quot ant[Ares]][/quot] все что мы видим на самом деле этим не является. Начали с того, что "глупый" заказчик требует удалить все первичные ключи, а на деле выходит что ничего глупого не требуется. Объясняйтесь честно и люди к вам потянутся. А что сделать в этой, как оказалось совсем другой ситуации, MasterZiv подсказал. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2008, 18:27 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
iscrafm[quot ant[Ares]] все что мы видим на самом деле этим не является. Начали с того, что "глупый" заказчик требует удалить все первичные ключи, а на деле выходит что ничего глупого не требуется. Объясняйтесь честно и люди к вам потянутся. А что сделать в этой, как оказалось совсем другой ситуации, MasterZiv подсказал.[/quot] Что значит ничего глупого не требуется? Объясняю все как могу. И если внимательно прочитать весь топик то все будет понятнее. Подсказку MasterZiv'a я прочитал, принял к сведению. И другие советы и рекомендации тоже. Всем большое спасибо. Поэтому считаю, что обсуждение можно закрывать. Если кому то интерестно, то могу после очередных переговоров с заказчиком (ближе к концу недели) рассказать о результатах применения ваших советов на практике. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2008, 21:07 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
интересно ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2008, 23:07 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
Расскажите, по-профессиональному интересуюсь. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2008, 14:53 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
Собственно эпопея закончилась )) и довольно таки неплохо. Представительнице заказчика на повышеных тонах сказали что никто и ни при каких условиях просто не будет делать предложенную ими схему БД и что она может жаловаться кому угодно. После (уже нормальным тоном) попросили составить список причин по которым они не хотят использовать нашу схему. После нескольких часов(4+) разбора этого списка и обучанию их основам SQL они наконец сломались =)) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2008, 15:15 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
поздравляю ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2008, 16:11 |
|
как всегда проблемы с заказчиком
|
|||
---|---|---|---|
#18+
Стандартный алгоритм решения проблемы: 1) Запугивание (запугал полдела сделал) 2) Запутывание (еще 40%) 3) Наказание невиновных 4) Награждение не участвоваших Плохо, что последнии два пункта не выполнили. Не научно ______________________________________________________ Задолбали вихри яростных атак ... ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2008, 18:14 |
|
|
start [/forum/topic.php?fid=33&gotonew=1&tid=1548835]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
64ms |
get topic data: |
13ms |
get first new msg: |
9ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
others: | 274ms |
total: | 458ms |
0 / 0 |