Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
Nitro_Junkie
в задачах нужны именно объекты и свойства, а не таблицы и строки). Или вы про 2-ю НФ не согласны?

Согласен, но таблицы нужны для применения к ним рел. алгебры. У объектов никакой алгебры нет, поэтому никаких серьезных задач на них решать нельзя.


Это вопрос что вы под алгеброй понимаете... в любом случае все то что до 2 НФ в SQL'е избыточно...
16 дек 09, 15:17    [8076033]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
Чистые функции - хороший стиль программирования. Если надо чего-то менять - исп. процедуры.
Объект - это набор св-в, методы нужны только для изменения этих св-в. Узнать значение св-ва можно без всяких методов. Ваши примеры - это использование терминологии ООП там, где оно вообще не применимо (типа притянуто за уши).

Что-то я запутался. Вы сначала говорили что такого понятия как функции\процедуры в ООП нету, что там есть только классы, объекты, поля и методы... Теперь даже есть чистые функции и соответственно исп. процедуры - или это вы про структурное программирование?

В любом случае допустим если я пишу на Java и мне нужно реализовать описанный мной функционал (про Query), мне с точки зрения ООП как его надо оформлять?


_мод
Это одно и тоже.


Но вы мне так и не ответили на вопрос, можно ли наследовать типы данных в C. То есть сказать что тип данных A находится в каком-то отношении с типом B, что все поля типа B по определению есть в A.
16 дек 09, 15:23    [8076101]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
Это вопрос что вы под алгеброй понимаете

набор операций над отношениями, реализованные сначала Коддом в алфе а потом в SQL.
Такого набора для объектов не существует, т.е. алгебры объектов нет.
16 дек 09, 16:42    [8076764]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
Теперь даже есть чистые функции и соответственно исп. процедуры - или это вы про структурное программирование?

Просто программирование.
Nitro_Junkie
мне с точки зрения ООП как его надо оформлять?

с точки зрения ООП далеко не все можно реализовать (формально оформить можно только зачем ?)
Nitro_Junkie
что все поля типа B по определению есть в A.

можно - по построению
16 дек 09, 16:45    [8076792]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
Nitro_Junkie
Это вопрос что вы под алгеброй понимаете

набор операций над отношениями, реализованные сначала Коддом в алфе а потом в SQL.
Такого набора для объектов не существует, т.е. алгебры объектов нет.


Вполне отлично существуют, например частично-рекурсивные функции... Которые появились задолго до SQL. Там есть 5 операторов при помощи которых можно задать любую вычислимую функцию. Оперирует объектами (если ассоциировать любой объект с числом, предполагая что мн-во объектов счетно). Отлично подходит под ваше определение алгебры. И кстати можно считать были прообразом для реляционной алгебры - операторы подстановки как Join'ы, операторы примитивной рекурсии - рекурсивные CTE, группировки как операции минимизации аргумента...
16 дек 09, 16:50    [8076839]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод,

Видимо мы про какие-то разные ООП говорим... Лично я говорю о классическом, который лежит в основе Java, C# и иже с ними... Где есть классы с полями и методами (как функциями принадлежащему одному объекту\классу к которому можно обращаться через this), есть static методы как функции (но для них принадлежность одному классу выглядит еще более дебильно), которые вообще противоречят ООП... Процедуры соответственно являются частным случаем функций, которые ничего не возвращает, то есть отдельно не рассматривается. Касательно mutability в ООП вообще ничего не сказано. Ну и плюс сверху области видимости, чисто как безопасность. Могу накидать кучу ссылок из википедии, бутча и иже с ними где все что я сказал подтверждается...

Может все-таки поделитесь своим представлением об ООП?
16 дек 09, 17:00    [8076922]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод,

И программирование - это очень абстрактное понятие, в которое и SQL и логическое программирование (как базы знаний) и чего только туда не входит. Так что про функции и процедуры, что они входят в программирование это все же перебор....
16 дек 09, 17:04    [8076954]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
web_fox
Member

Откуда: Киев
Сообщений: 444
Nitro_Junkie,

Мне симпатична идея, озвученная _мод, что метод должны менять только свойства обьектов. Что-то в этом есть. Примерно как в Оракле нельзя дмл в селекте делать. Порядок появляется что-ли, предсказуемость.

Само собой, что чем более технология программирования ближе к реальному миру в которым мы существуем, тем легче/интуитивнее на ней будет релизовывать модели этого же мира. Поэтому SQL и стал популярным - он ближе к нашему пониманию.

Вот идею о чистых функциях пытаюсь себе смоделировать. Сижу смотрю сейчас на блок музыкального центра (объект). Вот я ему вызвал метод Повернуть_ручку_звука (по_часовой_стрелке, 10_градусов). А как я звук услышу? Получить через return или должен прочитать его свойство? Инициатива исходит от меня? - нет, инициатива исходит от музыкального центра, именно он воздействует на меня звуком. Т.о. есть "воздействие", "обьект воздействия" и "характер воздействия" - метод, объект и параметры метода. Я воздействую на него, а он воздействует на меня. Причём я оказываю воздействие адресно, а он безадресно. Мы взаимодействуем. Наверное, в идеальном языке программирования должно быть что-то типа такого - взаимных воздействий - поддержка эвентов на уровне языка. Чтобы задача моделирования, например, человека и музыкального центра программировалась as is. А потом на этом же языке нужно как-то сделать воздействие на СУБД, хм. Можно ли это всё смоделировать на полностью декларативной парадигме? В UML есть разные типы диаграмм: описание статики, динамики, состояний... Гда та одна универсальная UML-диаграмма, одна универсальная парадигма? [Спокойной ночи]
17 дек 09, 00:55    [8078257]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
web_fox
Member

Откуда: Киев
Сообщений: 444
ммм, а это не Objective-C случайно? 8)
17 дек 09, 01:09    [8078274]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
Вполне отлично существуют, например частично-рекурсивные функции...

????
таблица3=таблица1 операция таблица2 - так можно
объект3=объект1 операция объект2 - а так низзя
17 дек 09, 09:27    [8078592]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie

Лично я говорю о классическом, который лежит в основе Java, C# и иже с ними... которые вообще противоречят ООП...

Точнее не скажешь :)
17 дек 09, 09:29    [8078601]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
И программирование - это очень абстрактное понятие

У Дейкстры есть книжка "Дисциплина программирования" - я об этом.
17 дек 09, 09:31    [8078612]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
web_fox
Можно ли это всё смоделировать на полностью декларативной парадигме?

Может и можно, вот только зачем ? Воздействие предполагает императивность. Например, программа управления роботом д.б. набором команд. Ну и т.д.
17 дек 09, 09:36    [8078630]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
Может все-таки поделитесь своим представлением об ООП?

Дейкстра сказал, что эта парадигма была придумана исключительно для разработки оконного интерфейса. Такая одноразовая штука.
17 дек 09, 09:41    [8078657]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
web_fox, _мод

Immutable объекты гораздо более предсказуемы чем mutable объекты... Для них можно делать Lazy Evaluation, их можно безопасно передавать другим объектам, и те не будут боятся что переданный объект вдруг без их ведома неожиданно изменится. Но как правило не стоит выбор что делать класс Immutable или Mutable, это определяется задачей\архитектурой. Например в текущем проекте все классы не связанные с хранением текущей информации от пользователя (пример такой информации является тот же музыкальный центр) Immutable а их 90%. Получается что им вообще не место в ООП, что же мы тогда, прости господи, используем за программирование в нашем проекте?

Забавно что оказывается достаточно много людей которые считают что ООП хоть что-то говорит о mutability объектов. ООП это просто надстройка над структурным программированием (о котором писал Дейкстра), в котором добавлена возможность наследования, необходимость запихивать функции в классы и область видимости. А уж особенно противопоставлять его структурному программированию это в стиле акции пчелы против меда.
17 дек 09, 10:13    [8078832]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод

таблица3=таблица1 операция таблица2 - так можно
объект3=объект1 операция объект2 - а так низзя


Вот ваше определение алгебры :

набор операций над отношениями.

Так вот в случае частично-рекурсивных функций, отношения это функции, операции - операторы создающие новые функции.

И даже для вашего примера вполне обычное структурное программирование подходит:

andWhere = and(where1,where2);

если предположить что класс Where immutable
17 дек 09, 10:16    [8078866]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
web_fox
Можно ли это всё смоделировать на полностью декларативной парадигме?

Может и можно, вот только зачем ? Воздействие предполагает императивность. Например, программа управления роботом д.б. набором команд. Ну и т.д.


Я уже писал:
Безотносительно нашего проекта, можно узнать почему? Я понимаю что у любого расширения должны быть императивные черты, чтобы реагировать на события, но если их формализовать в виде например ввода свойства или изменения класса объекта, а все остальное рассматривать как следствие декларативных правил, то почему нет.


И надо это затем что декларативное программирование по всем нефункциональным требования значительно превосходит императивное. Особенно это касается расширяемости, скорости разработки, надежности и т.д. В нем нету последействий, они более высокоуровневые как следствие их прозрачно проще оптимизировать, правила гораздо более "портабельны" чем императивные алгоритмы и т.п.
17 дек 09, 10:22    [8078897]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
Nitro_Junkie
Может все-таки поделитесь своим представлением об ООП?

Дейкстра сказал, что эта парадигма была придумана исключительно для разработки оконного интерфейса. Такая одноразовая штука.


Мало ли чего он сказал... Если он не понимает ценности наследования, то архитектор из него нулевой. Хотя как алгоритмист он может и впереди многих...
17 дек 09, 10:24    [8078904]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Nitro_Junkie
_мод
Nitro_Junkie
Может все-таки поделитесь своим представлением об ООП?

Дейкстра сказал, что эта парадигма была придумана исключительно для разработки оконного интерфейса. Такая одноразовая штука.


Мало ли чего он сказал... Если он не понимает ценности наследования, то архитектор из него нулевой. Хотя как алгоритмист он может и впереди многих...
а вот тут люди не менее уверенно утверждали что наследование и не нужно
17 дек 09, 11:05    [8079188]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
SergSuper,

А че мелочится, тогда уже циклы и функции не нужны, условные и безусловные переходы рулят... Если людям не надо наследование, то это характеризует не его ценность, а самих людей, их уровня как разработчиков.
17 дек 09, 12:13    [8079678]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
Так вот в случае частично-рекурсивных функций, отношения это функции, операции - операторы создающие новые функции.

Таблицы, функции - это одно множество один тип данных. А объекты все разного типа - видите разницу ? Над элементами одного типа можно строить алгебру, а на элементах разных типов - нет.
17 дек 09, 12:31    [8079823]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
И надо это затем что декларативное программирование по всем нефункциональным требования значительно превосходит императивное.

Схоластика. Набор команд - это тоже декларация.
17 дек 09, 12:33    [8079851]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Nitro_Junkie
SergSuper,

А че мелочится, тогда уже циклы и функции не нужны, условные и безусловные переходы рулят... Если людям не надо наследование, то это характеризует не его ценность, а самих людей, их уровня как разработчиков.
не, ну Вы почитайте, там у людей аргументы были
17 дек 09, 12:34    [8079857]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
_мод
Guest
Nitro_Junkie
Если людям не надо наследование, то это характеризует не его ценность, а самих людей, их уровня как разработчиков.

Людям надо и они его давно используют, но только правильно, как конструктор новых типов данных. Посмотрите хотя бы эйфорию.
17 дек 09, 12:39    [8079902]     Ответить | Цитировать Сообщить модератору
 Re: SQL - полнота по тьюрингу  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
_мод
Nitro_Junkie
Так вот в случае частично-рекурсивных функций, отношения это функции, операции - операторы создающие новые функции.

Таблицы, функции - это одно множество один тип данных. А объекты все разного типа - видите разницу ? Над элементами одного типа можно строить алгебру, а на элементах разных типов - нет.


Объекты как раз все одного типа - мы ассоциируем их с номерами, то есть просто натуральными числами (забыли про наследование, оно в построении алгебры роли не играет). Функции соответственно интерфейсы объектов (множественные). То есть никакой разницы...

ЗЫ. Функции в частично рекурсивных функциях могут иметь значение undef (null по русски). То есть с точки зрения классических типов данных (программирования), если функции передается объект не того типа, то она просто возвращает undef.
17 дек 09, 12:46    [8079961]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить