Типы данных БД

бред какой-то

и что же тут бредового?

У всех типов данных только два общих параметра: название и максимальный размер. Что еще может быть общего у типов numeric(p,s), char(n), blob, clob, nchar(4), bfile, date, timestamp, всякие вложенные таблицы, массивы, объекты? Параметр «максимальный размер» зависит не только от названия СУБД, но и от версии. Параметров, описывающих тип, можно придумать тучу, но каждый из них будет характерен только для определенной группы типов.

Насчет родственных типов - в одних СУБД, какие-то два типа могут быть роднее, чем в других

Могут, это их право. Данная задача заключается именно в формализации свойств базовых типов данных для любой произвольно взятой СУБД. Необходимость в родственных типов отпадает сама собой, если для 99% СУБД (столбец BIGINT не может ссылаться на INT, или INT на SHORT INT), а если хоть в одной распространенной СУБД это возможно, то без него никуда.

Два параметра (length и precision) - это хорошо, а как тогда быть с массивом varchar'ов в том же posgresql? или с массивом float или numeric? Видимо необходимо добавить еще флаг «является массивом».

Попробую объяснить так: Пусть, существует класс «Тип Данных», набора свойств которого хватит для описания любого типа любой БД. И есть куча подгружаемых библиотек (плагинов), каждая из которых экспортирует список типов данных для конкретной (одной) СУБД. Плагин может не использовать все свойства класса «Тип Данных». Но набора свойств должно хватить для описания любого типа данных любой СУБД.

Надеюсь, что так понятнее.

Класс будет с такими свойствами
name,
length,
precision,
scale,
lengthInBytesOrChars,
bytesInChar

isDate,
isNumber,
isChar
isBlob,
isArray,
isNational,
isAutoIncrement
is ....
и т.д.
Количество полей зависит от списка поддерживаемых СУБД

еще кодировка и User-Defined Types, ANYTYPE, ANYDATA, ANYDATASET

Пусть, существует класс «Тип Данных», набора свойств которого хватит для описания любого типа любой БД. И есть куча подгружаемых библиотек (плагинов), каждая из которых экспортирует список типов данных для конкретной (одной) СУБД. Плагин может не использовать все свойства класса «Тип Данных». Но набора свойств должно хватить для описания любого типа данных любой СУБД.

Подход неверный, такой класс будет перегружен мусором и практически с ним будет невозможно рабобать. Нужно делать простой, базовый, класс для всех типов и от него уже наследовать классы для конкретных категории типов в СУБД со своими уникальными свойствами/методами.

посмотрите в MySQL базу Information_Shema - там как раз описывается метаинформация других баз. Насколько я понял вы что-то подобное и ищите..

ЩИТО?! В пг нету даже первой нормальной формы? В которой четко сказано, что все данные должны быть атомарны

ЩИТО?! В пг нету даже первой нормальной формы? В которой четко сказано, что все данные должны быть атомарны

>Какими необходимым и достаточным набором свойств можно охарактеризовать любой тип данных любой реляционной СУБД?

В чем смысл жизни?

Конечно. нет. Никто кроме тебя даже и не знает что это такое.

>Какими необходимым и достаточным набором свойств

Необходимый для чего и достаточный для чего?

> Необходимый для чего и достаточный для чего?

Необходимый и достаточный для описания любого типа. Там так и написано.

Класс будет с такими свойствами name, length, precision, scale, lengthInBytesOrChars, bytesInChar

isDate, isNumber, isChar isBlob, isArray, isNational, isAutoIncrement is .... и т.д. Количество полей зависит от списка поддерживаемых СУБД

isDate
isNumber
isBlob
... etc

лишние. Мне не нужно их реализовывать, нужно только описать набор свойств. На примере:

• varbinary(N) отличается от varchar(N) только названием.
• datetime отличается от integer, только возможностью autoincrement'a (хотя надобность этого свойства неясна, в силу sequences)

какой смысл несет в себе isNational? Мне не приходилось сталкиваться.

> Подход неверный, такой класс будет перегружен мусором и практически с ним будет невозможно рабобать. Нужно делать простой, базовый, класс для всех типов и от него уже наследовать классы для конкретных категории типов в СУБД со своими уникальными свойствами/методами.

Там правильнее было бы сказать структура. Да, некоторые поля не будут использоваться некоторыми «плагинами». Но с другой стороны оверхэд не большой, поскольку большая часть из них - флаги. А вот работать с универсальным типом, мне кажется, будет проще. Поскольку не придется для каждой СУБД загружать свой тип структуры, и определять потом как с ним работать.

P.S. Вообще хочу написать/пишу визуальный редактор sql, с возможностью генерации ddl скриптов. Желание родилось после просмотра ужаса на бейсике с названием pgDisigner, который падает от каждого чиха. Но тут на ЛОРе пробегала информация, что это лучшее, что есть под линукс. Так что вот...

визуальный редактор SQL? проще сам SQL выучить пользователю, чем осваивать такие «визуальные редакторы» с 3 возможностями.

> Вообще хочу написать/пишу визуальный редактор sql, с возможностью генерации ddl скриптов.

Ну и кому будет нужен такой редактор? Серьёзно.

Я смотрю, ты можешь помочь, ага. Флудом скор зарабатываешь?

Я смотрю, ты можешь помочь, ага. Флудом скор зарабатываешь?

Я смотрю, ты не можешь даже аргументировать необходимость создания твоей программы.

Хорошо, 1) чем, по-твоему, будет более удобно составлять SQL-запросы в визуальной среде по сравнению с набором кода; 2) какую мощность запросов будет поддерживать твой редактор с учётом поддержки всех баз данных?

В реальных приложениях сложность SQL-кода приближается к сложности языка программирования. А мы знаем, что до сих пор программы составляются простым набором кода, а не визуальным редактированием (визуализируется, по крайней мере, только первичный этап - проектирование - на языке UML, но на нём ведь тоже можно проектировать структуру баз данных). Сомневаюсь, что логику триггеров и т.п. возможностей будет легко реализовать в общем визуальном виде.

Кроме того, в PgSQL возможен такой код:

SELECT ts_rewrite('a & b'::tsquery, 'a'::tsquery, 'c'::tsquery);
----------
SELECT ts_rewrite('a & b'::tsquery, 'SELECT t,s FROM aliases');
----------
SELECT * FROM ts_stat('SELECT vector FROM apod')
ORDER BY nentry DESC, ndoc DESC, word
LIMIT 10;

Ну а если не реализовывать подобное, то особого толка от использования данной программы будет немного. Для неспециалистов и новичков она будет черезчур сложной, а для профессионалов - недостаточно мощной (да и написать код руками для них явно удобнее). В связи с этим и возникает вопрос: «А для кого предназначено будет разрабатываемое ПО?»

Если же планируется создать «админку бд», то её стоит делать применительно к одной конкретной субд, и то, большая часть запросов не будет осуществляться визуально, а будет сделана через вбивание SQL руками.

Я смотрю, ты даже прочитать не можешь что написано, при чем тут «конструировать запросы»? Где я такое говорил? Цель программы - проектирование БД с возможность генерации скрипта DDL. Про «запросы» я ни слова не говорил.

Планируется что-то вроде Database Designer, Enterprise Architect.

> Я смотрю, ты не можешь даже аргументировать необходимость создания твоей программы.

Я уже писал выше необходимость создания нативной версии программы подобного типа.