StalkerSмоему вышеуказанному примеру. Я не технолог, и НЕ ОБЯЗАН ПОНИМАТЬ смысловую нагрузку этих имен.
Но Вы беретесь проектировать базу, в которой эти данные (не имена) будут обрабатываться. Сильно. Уважаю.

Единственное, что я готов представить - эти данные идут через вашу систему "транзитом". То есть она дает кому-то их ввести, кому-то их прочитать - и все. Если так - я бы, наверное, сделал инкапсулирующий их объектный тип с именем наподобие OtherData. А поля - можно придумать имена, можно и назвать f1, f2, f3 - будет не слишком плохо. К нормальному процессу это отношения не имеет.

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

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

Есть такая теорема - грубо говоря, если станок изготовлен с допуском деталей X, он физически не сможет выдавать детали с допуском менее X. Реально, даже с собственным уровнем допуска - не сможет, будет вносить дополнительную ошибку. Вы идете по пути именно этого станка. Вы - проскакали по процессу; Ваша система будет работать с еще большим допуском...

Реально Вы просто переносите центр тяжести с проектирования на внедрение.

StalkerSуможно придумать имена, можно и назвать f1, f2, f3 - будет не слишком плохо
нет, будет плохо, так как эти поля используются во многих запросах для нескольких клиентских приложений,
и разбираться через год, что за поле f12 в таблице tab29 я не собираюсь.
А Вы и сейчас в этом не разбираетесь. Поэтому в комментарии, либо в ER-инструменте можно написать нормальное русское имя, которое поймет "технолог". Вам, чтобы написать запрос, все равно придется подглядывать в шпаргалку или пользоваться каким-нибудь визуальным инструментом - так почему бы не пользоваться родными буквами вместо кривых?


>Tov_ID, Oper_No, Tov_Name...
а чем русские-то имена не нравяться ?
Oper_No - НомерОперации, чем плохо ?
а имена Oper_No, Tov_Name понятны только тебе, но никак не человеку, которому не дай бог придется в твоем коде разбираться[/quot]

gardenman4)Использование CASE средств - абсолютно не является гарантией того, что построенная с их помощью модель будет хорошей.
Безусловно. В общем случае это инструмент, который помогает построить модель (хорошую или плохую - зависит от разработчика) быстрее; кроме того, он автоматизирует некоторые тупые действия, и тем сокращает количество технических ошибок и их исправлений.

gardenman Даже наоборот.
А вот это ни из чего не следует.

gardenman В том, что показывает тот же дизайнер не видно кучи вещей - триггеров, констрэйнтов.
В том, что показывает SQL*Plus, их тоже не видно. Во всяком случае, напрямую.

Если считать, что CASE средство сварит разработчику кофе и принесет в постель, одновременно в фоне работая ЗА разработчика - конечно, до этого еще далеко. Хотя реклама может быть и такая. А так - можно долго сравнивать различные инструменты; в итоге все равно все подбирается "под себя".

Cat2 Мне это напоминает ситуацию, с использованием национальных алфавитов в именах файлов. В свое время это была проблема.
И много Вы видели дистрибутивов, файлы в которых имеют национальные имена?

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

StalkerSмда, буквально сегодня разбирали одну базу, поставляемую с одним конструкторским пакетом, так вот там было поле с названием naim_props,
Меня более впечатляет "стандартное" поле в куче систем: KORR_ACCOUNT.