|
|
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
egorychпредложенные префиксы как у таблиц, так и у вьюх навязывают клиенту БД знание, которое ему абсолютно не нужно, а в некоторых случаях ещё и вредно. И всё это ради сомнительного удобства быстро найти объект в списках менеджера? в топку такие префиксы :) Что подразумевается в понятии клиент БД? Если пользователь, то он вообще не будет этим пользоваться, он будет пользоваться непосредственно Клиентской программой, а она уж сама всё разрулит! А если программист БД, то мне кажется в запросе сразу будет видно где искать необходимый объект! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2008, 22:27 |
|
||
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
В Оракле есть представления словаря БД ALL_CATALOG, так что выяснить тип отношения не составляет труда. Однако, запросы к представлениям приходится делать с большой осторожностью, поскольку их эффективность может оказаться просто катастрофической. Посему я использую суффикс _V. Вообще, довольно редко представленя БД удаётся использовать повторно, так что на счёт их названий можно особо не париться. В идеале представления и таблицы должны быть взаимозамеяемыми. С этой позиции различать их не есть хорошо, ведь рано или поздно отношение, которое было таблицей может стать представлением и наоборот, а украшения названий только внесёт путаницу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2008, 04:01 |
|
||
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
mcureenab пишет: > Это только пример не претендующий на полноту. В паспорте этот атрибут Ну я и дополнил :-) Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2008, 13:12 |
|
||
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
Leximus пишет: > А как вы считаете, префикс таблицы должен быть или нет? Нет. > Мне кажется что удобно былобы в запросе сразу видеть что и к какому типу > относится! Для этого есть алиасы таблиц, которые в запросах обязательно должны и так использоваться для сложных запросов. Ведь например если запрос из представления то его долго можно > искать в списке таблиц в менеджере! А вы как считаете? Чего его искать -то ? не понял нифига. У него есть имя, оно уникально, взял да нашел. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2008, 13:14 |
|
||
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
Aviant пишет: > вот поэтому у представлений и имеет смысл делать префикс. > У таблиц - нет Чем таблица от представления функционально отличается ? Ничем. Так что и префиксов не надо. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2008, 13:17 |
|
||
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
mcureenab пишет: > В Оракле есть представления словаря БД ALL_CATALOG, так что выяснить тип > отношения не составляет труда. Это есть практически во всех современных СУБД, Однако, запросы к представлениям > приходится делать с большой осторожностью, поскольку их эффективность > может оказаться просто катастрофической. Так не надо делать такие вьюхи просто. > Вообще, довольно редко представленя БД удаётся использовать повторно, > так что на счёт их названий можно особо не париться. Если его нельзя использовать повторно, то на фиг оно вообще нужно ? > В идеале представления и таблицы должны быть взаимозамеяемыми. С этой > позиции различать их не есть хорошо, ведь рано или поздно отношение, > которое было таблицей может стать представлением и наоборот, а украшения > названий только внесёт путаницу. Во, это -- правильная мысль. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2008, 13:20 |
|
||
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
Nafкстати вопрос, таблицы именовать в единственном числе али множественном? Народ! Каждый делает как ему удобно, но если рассуждать здраво, что такое таблица? Как нам правильно напомнил MasterZiv, это сущность. Вот от этого и надо плясать. Если у меня в таблице хранится список контрагентов, например, тогда логично назвать ее Customer, а вот если там связь, скажем, между каждым студентом и семестрами, в которых он учился, тогда StudentSemesters. Допускаю что я где-то могу быть неправ, однако, по моему скромному мнению, тут вопрос принципиальный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2008, 18:51 |
|
||
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
Leximus egorychпредложенные префиксы как у таблиц, так и у вьюх навязывают клиенту БД знание, которое ему абсолютно не нужно, а в некоторых случаях ещё и вредно. И всё это ради сомнительного удобства быстро найти объект в списках менеджера? в топку такие префиксы :) Что подразумевается в понятии клиент БД? клиент БД, естественно, подразумевается клиентская программа, пользователю вообще вредно знать, что есть какая-то там БД :) mcureenab и MasterZiv фактически ответили за меня и я с ними полностью согласен. Pan Vlad... однако, по моему скромному мнению, тут вопрос принципиальный. а по моему не менее скромному - абсолютно нет :) ибо это не тот вопрос, из-за которого стоит ломать копья, как кому удобней, тот так и называет. Главное здесь, чтобы было понятно, какую сущность собой представляет отношение (как таблица, так и представление). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2008, 21:27 |
|
||
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
MasterZivОднако, запросы к представлениям > приходится делать с большой осторожностью, поскольку их эффективность > может оказаться просто катастрофической. Так не надо делать такие вьюхи просто. Разные ситуации бывают. Код: plaintext Скорее всего будет работать как положено. Работоспособность Код: plaintext Будет зависеть от <predicate>. Запрос Код: plaintext Наверняка потребует настройки, если вообще не придётся создавать специально заточенные под него представления. Утешает только то, что с каждым годом СУБД становятся умнее и лучше решают задачи оптимизации сложных SQL запросов. MasterZiv > Вообще, довольно редко представленя БД удаётся использовать повторно, > так что на счёт их названий можно особо не париться. Если его нельзя использовать повторно, то на фиг оно вообще нужно ? Например, для декомпозиции сложного SQL запроса на несколько простых, чтобы читаемость запроса улучшить, уменьшить объём сетевого трафика на передачу текста SQL запроса, разместить логику отбора данных на стороне СУБД, обеспечить разграничение доступа на уровне строк. Иногда приложение БД налагает ограничения на синтаксис SQL запросов, так что запрещённые фразы приходится прятать в представление. В общем, как правило представление затачивается для решения довольно узкого класса задач и использовать его для решения других задач не эффективно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2008, 01:38 |
|
||
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
mcureenab пишет: > Например, для декомпозиции сложного SQL запроса на несколько простых, > чтобы читаемость запроса улучшить, уменьшить объём сетевого трафика на > передачу текста SQL запроса, О, да я погляжу, вы достойные проблемы там решаете... Особенно актуальна проблема сетевого траффика, создаваемого большими запросами. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2008, 14:48 |
|
||
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
Не претендую на "идеальную" систему наименований, вообще главное чтобы она была :) Различные системы наименований обсуждались неоднократно и как правило эти обсуждения превращались в филосовские войны. По вышеперечисленному придерживаюсь следующей: >>Все имена таблиц должны начинаться на символ “t” (Например “tUsers”). Таблицы именуются в единственном числе без префиксов . Для вьюх использую префикс (vUser). Многие предпочитают не использовать префикс ни для вьюх ни для таблиц. >>Поля в таблице делятся на следующие категории : Нет необходимости делить их по категориям. >>Имена полям таблицы присваиваются по следующим правилам: Поле ПК имеет всегда одно и тоже имя во всех таблицах (ID, SID или OID) Поле внешнего ключа именуется по правилу: TableName1TableName2ID (например: EmployeeDepartmentID) Наименование полей данных отражают их содержание, например, DocumentDate Примечание: MS, например не рекомендует оверхед, т.е. вместо DocumentDate рекомендует просто Date. Но на практике удобнее изначально иметь оверхед, чем вручную писать и путаться с алиасами при написании запросов. Также удобно при использовании различных генераторов хп и вью. Вообщем предпочитаю иметь уникальное название поля в рамках всей БД (исключение - ПК) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2008, 18:17 |
|
||
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
Роман ДынникВообщем предпочитаю иметь уникальное название поля в рамках всей БД (исключение - ПК)Тоже но с ПК в том числе <Префикс типа> + <ИмяТаблицы> + <УточняющийCуффикс> ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2008, 09:03 |
|
||
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
Роман Дынник Поле внешнего ключа именуется по правилу: TableName1TableName2ID (например: EmployeeDepartmentID) А что делать, если имеет место двойная (множественная) связь таблиц? Или FK ссылается на вторичный ключ? Да и ID подразумевает наличие суррогатного ключа, который может отсутствовать. В объектных БД ODI вообще скрыт от пользователя, так что PK можно выбирать живой. Выходит стандарты сильно зависят от подхода к проктированию БД, а так же от системных ограничений или расширений, так что для каждой БД скорее всего будут применяться свои стандарты именования объектов. Не важно какие, важно, чтобы они просто были и соблюдались. Интерес представляет просто перечень вопросов, на которые нужно дать ответ в процессе разработки стандарта. Готовые решения полезны только в качестве примера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 04:25 |
|
||
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
mcureenabВыходит стандарты сильно зависят от подхода к проктированию БД Выходит - Да :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 15:35 |
|
||
|
Правило создания таблиц!
|
|||
|---|---|---|---|
|
#18+
Фигня! Придумать Самый Лучший Самый Правильный способ именования - и опа! Все базы сами стремительно разработаются. Останется только сидеть в потолок поплёвывая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2008, 17:06 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=35121550&tid=1544040]: |
0ms |
get settings: |
7ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
172ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 204ms |
| total: | 480ms |
| 0 / 0 |
