bublikom,
я стараюсь именовать примерно так...
к примеру есть "сущности" user, host, online_user...
когда делаю таблицу для неё, добавляю _list - потом в коде, для меня это маркер что это именно таблица
то есть user_list, host_list, online_user_list...
если через PK на эту таблицу будут ссылаться, то соответствненно user_id, host_id...
online_user_id - довольно длинно, и я назвал бы ou_id или ouser_id
если PK больше нигде не нужен, то его просто называю id

и заглавных букв не использую )

bublikom, почитал ваш топик... понятно что вам не нравится...
вы хотите чтоб ваши таблицы как-то логически группировались в списке.. в EMS есть такая возможность.. .делать "папки" и там группировать что и как хотите...
либо приставку в виде одной буквы... сейчас как раз буду одну базку "реструктурировать", и таблички уже так обозвал, с приставкой... очень даже ничего в списке объектов всё по группам...

"поддчеркивания/заглавных букв"... ИМХО нерационально заморачиваться, что длинна названия таблицы была 33, а стала 37 символов... и Id <> ld ... латинские i и L очень похожи...
я так понял у вас несколько человек работают на проектом... так вот кто-то будет добросовестно писать GeoData... а кто-то раз нечайно напишет Geodata... ой каша потом будет...

а потом будет весело, когда привыкнешь выделять слова заглавными буквами... и делаешь что-нить на FireBird... где токо в одном регистре можно именовать...
или на Postgres, где GeoData <> Geodata

вы ещё на кирилице имена объектов попробуйте делать... будет вообще очень наглядно )

про голый id, я говорил что использую его в случаях, где он нигде не нужен, то есть на него не ссылаются.

без префиксов плохо... в базе есть разные объекты, их по разному используешь... к примеру
user_list - список пользователей (можно tbl_user)
view_user_list_login - список для формы логина
view_user_list_adm - список для формы администрирования
fun_user_access(...) - функция возвращающая права пользователя
proc_user_save(...) - хранимка для сохранения данных пользователя
proc_user_delete(...) - храника для удаления пользователя

чтобы сгрупировать в списке... например есть ещё ряд таблиц относящихся к user... с префиксами рядом будут
user_list - список пользователей
u_access_list - таблица прав пользователей
u_show_settings_list - настройки отображения для пользователей
u_events_log - лог событий пользователей

в запросах всё через алиасы...
SELECT * FROM user_list AS a
LEFT JOIN u_show_settings_list AS b ON a.user_id = b.user_id

разбивать по схемам... пробовал... можно сказать только для того, чтобы "было лучше видно" 30 таблиц разнёс по 5 схемам... сейчас плююсь... я использую EMS и там для каждой схемы - отдельно дерево а не один список для всей базы... напряжно прыгать... монитор не такой большой как хотелось бы
буду всё скидывать в dbo...
наверно раскидывать по схемам имеет смысл, когда таблиц более 40, и разделяемы данные хоть и связаны, но относятся к разным "приложеням"... так сказать "большие" логические группы...
и если нет ньюансов с правами, то удобно их назначать... одной командой, на схему )

по поводу "не целесообразности"... дело конечно Ваше... и мои "правила" только моё ИМХО... меня очень устраивает )

в же потом напишите на чём остановились... любопытно )

bublikom про схемы. тут подробнее, почему плюетесь? . понятно, что будут роли дающие права на часть или на все схемы. в чем проблема? таблиц думаю будет 50 (до сотни предположительно)
плююсь, что неудобно прыгать при кодировании между разными схемами, да и разделение прав по схемам - не сработало... таблицы/процедуры очень взаимосвязаны, так что для каждых ролей права всё равно в ручную пообъектно выставлять приходится...
то есть хотел упростить себе работу с назначением прав - не вышло
хотел чтобы было логически сгруппировано - тоже не удобно, далеко прыгать
лучше сгруппировать в одном месте с преффиксами...

ещё раз повторюсь... ИМХО схемы, наверно имеют больший смысл, когда в одной базе какие-то очень разноплановые данные... у которых не так много связей между собою, или нет вообще... гипотетический пример... в одной БД надо уместить - база по документам, по земельным участкам и... допустим по органиациям...
тут общее что... список пользователей c инд.настройками... между базами по 0..2 связи
я бы сделал четыре схемы:
- user_ch (ch=chema)
- doc_ch
- org_ch
- zem_ch
с правами это вряд-ли что-то упростит, а вот процесс разработки будет намного проще... это по сути разные "приложения"

опять же, это всё зависит от того что за приложение...
одна крайность - это когда я 30 таблиц по 5 схемам раскидал, другая что мне попадалась, это когда ~1900 таблиц, и примерно столько же процедур - в одной схеме (dbo), хотя я бы там выделили с 2 десятка логических "подгрупп"... было бы на порядк проще ориентироваться