|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
RC2 на свежесозданной базе через ISQL выполняю запрос Код: sql 1. 2. 3. 4. 5. 6. 7.
возвращаются строки, у всех в поле RDB$SYSTEM_FLAG стоит 1 (понятно, создано системой) Создаю домен (пример из руководства) Код: sql 1.
Потом снова выполняю первый запрос к RDB$FIELDS. Визуально - никаких изменений. Нет там строки с CUSTNO. Но если заново попытаться создать этот домен, то выдается ошибка, что в RDB$FIELDS нарушение ключа, таблицы на этом домене успешно создаются, т.е. где-то внутри машинки эта строка таки вставлена, просто наружу через ISQL она ее не показывает. При следующем соединении с базой домен CUSTNO в таблице виден, но если создавать другие домены - ситуация повторяется. Это нормально? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2016, 19:28 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
U-geneЭто нормально? Нормально. Умолчательный уровень транзакции - snapshot, она не видит то, что навставляла отдельная DDL транзакция. Используй SHOW DOMAINS вместо того чтобы лезть в системные таблицы. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.03.2016, 19:33 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
задумчиво ... то есть вы хотите сказать, что ежели столбец определен на базовом типе (например INTEGER), то машинка автоматом создает под конкретно этот столбец уникальный "номерной" домен? но если столбец создается на явно определенном домене, то этот домен "используется" многократно? Получается, что ежели я создам свой домен Код: plaintext
Почему так? Ведь с точки зрения логики, тот же INTEGER - предопределенный домен. Есть какой то глубокий смысл в создании "номерных" доменов под каждый столбец? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 05:11 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
U-gene, Домен - это еще NULL/NOT NULL и DEFAULT. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 09:32 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
U-gene, И CHECK еще... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 09:34 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
DarkMaster, Оно всё так. Проверил, создал таблицу со столбцом Код: plaintext
Но последующие ограничения и дефолты прописались в RDB$RELATION_FIELDS и в RDB$RELATION_CONSTRAINTS (а не в RDB$FIELDS, хотя там соответствующие поля есть и, когда я создаю домен с ограничениями и дефолтами, они пишутся именно туда.). Выглядит, как будто с точки зрения системы номерной домен RDB$32 полностью аналогичен просто INTEGER. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 11:44 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
U-gene, Поле "перекрывает" домен... Т.е. если у поля допустим тот же Default отличается от доменного - возьмется default от поля. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 12:01 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
U-gene, Создаем домен: Код: plsql 1. 2. 3. 4. 5.
В RDB$FIELDS получаем 1 новую запись, описывающую домен. Создаем таблицу с 2 полями BOOL, причем у последнего перекрываем DEFAULT Код: plsql 1. 2. 3. 4. 5.
В RDB$RELATION_FIELDS получаем еще 2 поля B1,B2, которые имеют домен BOOL (оба). В RDB$FIELDS новый домен (системный) получим только для ID. Движек сначала смотрит на домен привязанный к полю в RDB$RELATION_FIELDS и если такой пользовательский домен есть в RDB$FIELDS, то "правила поведения" поля строится как "сначала правила из домена" + "перекрытие правил из RDB$RELATION_FIELDS". ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 12:14 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
U-gene, автоматически создаваемые домены это рудимент. Просто так придумали когда-то давным давно. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 12:16 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
DarkMaster, Я понял, я не так спрашиваю. Я говорю про домены, а имею в виду внутреннюю кухню СУБД. Для целочисленного поля таблицы система внутри себя создает новый номерной домен (типа RDB$32). Этот домен не виден пользователю, речь идет о записях в системных таблицах. Для другого целочисленного столбца она создаст другой домен, (какой-нибудь RDB$35) По содержимому системных таблиц, описывающих домены, оба этих домена друг от друга (и, по смыслу, от просто INTEGER) никак не отличаются (кроме имен). На первый взгляд, было логичнее один раз заранее внести запись о предопределенном домене, соответствующем INTEGERу, и использовать её для всех целочисленных столбцов - точно так же как используются явно создаваемые домены. Механизм то есть уже. Это позволило бы не плодить номерные домены. Почему возникла эта на мой первый взгляд нелогичная ситуация? Вы поймите, я без претензий, меня устроит любое объяснение, типа "так оно исторически сложилось" или "немножко быстрее", или вдруг есть какой-то смысл, которого я не понимаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 12:43 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
Симонов Денис, понял, спасибо, этот вопрос закрыт. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 12:44 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
DarkMaster, Это я понимаю. Вопрос был не про, как система работает с явно определяемыми доменами типа BOOL из Вашего примера, а про то, что для каждого INTEGER столбца система создает скрытый номерной домен. Сколько столбцов - столько таких скрытых доменов. Уже ответили. В любом случае - спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 12:50 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
U-geneВедь с точки зрения логики, тот же INTEGER - предопределенный домен. якобы, но несколько не так. integer - это физический тип. Домен - это логический тип. Причем, есть два варианта 1. определение домена как логического типа вообще, например "номер телефона" - строка с шаблоном проверки. 2. определение домена как конкретного логического типа, например, "номер телефона клиента", который не равен "номеру телефона отдела", хотя базовый тип и правила проверки у них могут быть одинаковыми. точно так же, id int not null для таблицы клиентов совершенно не равен id int not null для таблицы товаров. если переводить это в pascal, и еще больше усилить типизацию, то например type int1 = integer здесь int1 это уже будет "не integer", т.е. с integer для переменных типа int1 (и наоборот) нельзя производить сравнение и прочие операции. как-то так. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 13:22 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
kdv, C точки зрения РМД никаких "физических" (vs. "логических") типов нет. Есть домены, т.е. множества значений, на которых определены атрибуты отношений. Как эти множества задаются - это для РМД неважно, они просто есть. С точки зрения реализаций РМД, это конечно важно. Но это КМК не мешает рассматривать INTEGER не только, как что-то, связанное с физикой хранения, но и как логический домен, например со смыслом "число (чего-то)". Такое вот допущение. А, если без таких допущений и совсем строго заморочиться "логикой vs. физики", то надо прямое использование физического INTEGER при описании таблиц вообще запретить. На базе физического INTEGER(и др. физ. типов) создаем домены, и уж на таких доменах создаем таблицу. Это, кстати, не лишено смысла, но редкостное занудство. В общем, я предлагаю этой высокой темой дальше не заморачиваться :). Мой вопрос касался низкой физической физики. И спасибо за камент. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 14:23 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
U-geneC точки зрения РМД никаких "физических" (vs. "логических") типов нет. Есть домены, т.е. множества значений, на которых определены атрибуты отношений. я бы начал с того, что в большинстве СУБД никаких доменов вообще нет. А потом бы почитал хоть какие-то определения доменов, например тут http://citforum.ru/database/osbd/glava_16.shtml С другой стороны, Дейт не любит слово "домен", и вместо него в своей книге использует слово "тип". Однако, в любом случае, домен может быть создан только на основе базового типа, следовательно, домен в отношении к базовым типам вторичен, и сам по себе существовать не может (см. выше про отсутствие доменов в большинстве СУБД). Так что, в СУБД есть базовые типы данных, и есть "определяемые пользователем типы" (на основе базовых). (Дейт идет еще дальше, приравнивая домены и классы объектов, так что, грубо говоря, можно сказать что blob - это домен). U-geneНа базе физического INTEGER(и др. физ. типов) создаем домены, и уж на таких доменах создаем таблицу. Это, кстати, не лишено смысла, но редкостное занудство. бывают такие люди, видел их структуры БД. но это скорее перфекционизм, чем рациональное моделирование. U-geneя предлагаю этой высокой темой дальше не заморачиваться согласен. столь же бессмысленным был бы спор о том, где ставить ударение в слове "домен" - на первом слоге, или втором :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2016, 15:51 |
|
FB3 - непонятка.
|
|||
---|---|---|---|
#18+
kdv, Возможно я не так написал. C точки зрения теории никаких "физических" (vs. "логических") типов нет. Есть домены, т.е. множества значений, на которых определены атрибуты отношений. Как эти множества задаются - неважно, они просто есть. Меня в этом смысле в качестве "хоть какого-то определения домена" устраивает Мейер. http://www.studmed.ru/meyer-d-teoriya-relyacionnyh-baz-dannyh_7b820ba4d06.html (см. стр 10, пункт 1.2) Я, собсно, даже на термине "домен" не настаиваю, можно использовать что-то типа "область определения атрибута отношения". Смысл не меняется. Все остальное - "что правильно, тип или домен?", "где есть домены?", "что любит Дейт?" - это все относится к разным интерпретациям или реализациями этой теории . Здесь Вы правы, где-то "домены" есть, где-то их нет, кто-то это слово понимает так, кто-то - сяк. Но здесь у этого термина смысл немного другой - практический и системный. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2016, 12:01 |
|
|
start [/forum/topic.php?fid=40&msg=39201920&tid=1562264]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
55ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
others: | 269ms |
total: | 421ms |
0 / 0 |