SQL вопросик

[YellowMan]

Сообщение от AlexL

у жава спеца уйдет день работы без гарантии работоспособности кода.

Там дело намного хуже - видал я эту бадягу. Эта странная приблуда вместо пары строчек на SQL сгенерит скрипт на 1000 строк, в начале которого откроет транзакцию, залочит таблицы и начнет медленно пережевывать данные курсором.

[svu]

Сообщение от YellowMan

В угоду непонятно чему

Архитектурной правильности

Сообщение от AlexL

Вам уже указывали что спец по DB сделает ту же работу в два приема (две строчки) на что у жава спеца уйдет день работы без гарантии работоспособности кода.

Вы на php никогда не программировали?

[YellowMan]

Сообщение от svu

Архитектурной правильности

Смешно Не путай чертеж и реализацию - в какой архитектуре написано что код должен быть портированный?

[svu]

Сообщение от YellowMan

в какой архитектуре написано что код должен быть портированный?

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

[tpc]

Сообщение от svu

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

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

[svu]

Сообщение от tpc

это любая SQL субд обеспечит

Как СУБД (одна!) может обеспечить их разделение? Она же хранилище! Сам по себе факт запихивания БЛ в СУБД - уже отсутствие оного разделения (особенно мне нравится, когда параметры процедур объявляются в виде "тип такой-то колонки такой-то таблички").

А потом, для полноты картины, разработчики (те самые лабатели) начинают дергать эти самые процедуры прямиком из какой-нибудь jsp/php/... Пэстня. Дальше - лучше, менеджеры начинают создавть функциональные(!) спецификации приложения в терминах "данные из таблички ТТТ попадают на экран ЭЭЭ". И все - от большого уважения к данным и СУБД!

Мной было обнаружено, что в компании, успешно разрабатывавшая как бы жабские веб приложения в течении нескольких лет во всем CVS (во всех проектах) нет файла типа User.java ни в каком виде - ибо аутентификация проходила из фронтенда прямо в базочку. Убивав бы.

svu добавил 30.04.2010 в 14:22

Сообщение от tpc

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

Я плохой пророк, но мне почему-то кажется, вы рано закапываете. Закон Мура еще вернет вам ОО СУБД (и, в чем я уверен, реляционные будут вводить все больше и больше ОО фич). Ибо костыль по имени ОРМ действительно чреват всяким...

svu добавил 30.04.2010 в 14:23
http://en.wikipedia.org/wiki/Object_database

Starting in 2004, object databases have seen a second growth period when open source object databases emerged that were widely affordable and easy to use, because they are entirely written in OOP languages like Smalltalk, Java or C#, such as db4o (db4objects), DTS/S1 from Obsidian Dynamics and Perst (McObject), available under dual open source and commercial licensing.

[tadpole]

Сообщение от svu

В хорошей архитектуре должно быть написано разделение бизнес-логики и хранения.

В хорошей архитектуре целостность данных обеспечивается на уровне хранилища.

[svu]

Сообщение от tadpole

В хорошей архитектуре целостность данных обеспечивается на уровне хранилища.

Смотря что ты понимаешь под целостностью данных. Если высокоуровневые бизнес-правила, то это часть бизнес-логики. И тогда это не работа для хранилища.

[AlexL]

Сообщение от svu

Как СУБД (одна!) может обеспечить их разделение? Она же хранилище! Сам по себе факт запихивания БЛ в СУБД - уже отсутствие оного разделения (особенно мне нравится, когда параметры процедур объявляются в виде "тип такой-то колонки такой-то таблички").
(

Вот именно что Хранилище, а не свалка. Сама Таблица это уже элемент БЛ, ведь можно было бы сваливать все данные в файл и пусть потом приложение обрабатывает их. Далее, Поле таблицы еще один элемент БЛ, так как имеет определенный тип, а соотвественно и ограничения. Первичный ключ, Вторичный ключ, Уникальные индексы - также элементы БЛ. Глупо проверять уникальность информации вне базы данных, какой бы гениальной не казалась архитектура. Продолжая далее последовательно придем к тому что имеет каждая уважающая себя СУБД.

[tadpole]

Сообщение от svu

Смотря что ты понимаешь под целостностью данных.

Под целостностью данных я понимаю целостность данных. Они либо целостные, либо нет.

[tpc]

Сообщение от svu

Как СУБД (одна!) может обеспечить их разделение? Она же хранилище! Сам по себе факт запихивания БЛ в СУБД - уже отсутствие оного разделения (особенно мне нравится, когда параметры процедур объявляются в виде "тип такой-то колонки такой-то таблички").

как тут верно заметили Хранилище, а не свалка байтов. лично я как раз жутко страдаю теперь из-за оторванности бизнес логики от данных и поимел уже пару веселых вечеров.
вот например в одном из офисов кто-то умудрились накатить новый функционал на базу (DDL), жаба почему-то не обновилась. в результате туча хлама в базе, которую 2 недели разгребали. мне, оракловому дба это было настолько дико видеть, я думал эти проблемы остались в далеких 80х. в оракле бы логика разложенная по pl/sql пакетам пометилась бы как инвалид и субд не позволила бы запуститься инвалидной логике ни при каких условиях, вот оторванный от данных орм никто не проинформировал что структура пары таблиц изменилась и он как ни в чем не бывало запускал ставший кривым код. имхо огромный шаг назад в развитии.

ЗЫ. посмотрите данные Gartner, IDC доля ОО-субд сокращается и на данный момент меньше погрешности вычисления.

[YellowMan]

Сообщение от svu

Смотря что ты понимаешь под целостностью данных. Если высокоуровневые бизнес-правила, то это часть бизнес-логики. И тогда это не работа для хранилища.

Денис уже заметил - и прямо в точку. Целостность данных != бизнес-правилу и не может иметь двоякое толкование, и.е. или беременна или нет.
Тут в проектировании надо подходить с пониманием что натурально-связанные между собой данные должны быть целостными при любой бизнес-модели.
У человека всегда должны остаться одна голова и один ППС номер все зависимости от изменения внешних бизнес-моделей.

[svu]

Сообщение от AlexL

Сама Таблица это уже элемент БЛ

Она не элемент БЛ. Она - хранилище для структур данных, позволяющих наиболее эффективно реализовывать БЛ. В принципе, приложению должно быть пофиг, будет там БД или файл или ЛДАП какой-нибудь - лишь бы были удобные механизмы "вынуть-всунуть". Дайте удобный интерфейс хранения объектов - а на нижнем уровне хоть глиняные таблички испольуйте... Соббсно мой пойнт именно в этом - для прикладного ОО программиста сущность "БД" в некотором смысле лишняя. Это дело для ДБА и пр. Разработчику нужен гибкий универсальный интерфейс персистенции объектов. Безглючный и по возможности эффективный. Если этот интерфейс предоставляется (на сегодня) лучше всего реляционными СУБД (+ОРМ) - ура, я рад за их производителей. Пусть ускоряют индексы, вылизывают ОРМ, пусть сертифицируют дб админов - это замечательная и интересная ниша, в ней есть и будет много бабла - но прикладников это все не должно интересовать. Абстрагироваться от этих деталей реализации надо бы, по хорошему.

Сообщение от tadpole

Они либо целостные, либо нет.

Если в терминах http://en.wikipedia.org/wiki/Data_integrity, то не вижу противоречий. Пусть БД за них отвечает. Другое дело, что могут существовать высокоуровневые бизнес-правила, исключающие некоторые состояния объектов - их стоит реализовывать в бизнес-логике (и, изредка, вообще на фронтенде в виде валидации).

Сообщение от tpc

жаба почему-то не обновилась.

Проблемы на уровне менеджмента процесса разработки и поддержки - это для отдельного флейма. Они могут любое дело загубить А насчет "пометилась как инвалид" - мне страшно подумать, что Вы скажете о языках, где нет компиляции вообще

Сообщение от tpc

посмотрите данные Gartner, IDC доля ОО-субд сокращается и на данный момент меньше погрешности вычисления.

Статистика всякая бывает. Конечно, я вижу - пока оно тухло. Но чем чорт не шутит. Тем более что в Оракле и пр. объектные фишки не перестают добавлять. Вполне вероятно, однажды мы доживем до того, что оракл начнет нативно воспринимать какой-нибудь OQL, EJB QL (особенно любопытно, в свете покупкой ораклом сана). Тогда всем наступит щасте.

[YellowMan]

Сообщение от svu

Тогда всем наступит щасте.

Скорее - горе

Сообщение от svu

В принципе, приложению должно быть пофиг, будет там БД или файл или ЛДАП какой-нибудь - лишь бы были удобные механизмы "вынуть-всунуть".

В принципе, если приложение способно реализовать эффективные механизмы целостности данных во всем их великом разнообразии - то да, пофиг.
Но таких приложений нет - это то же самое что начать строить дом с посадки дерева из которого потом сделают крышу.

Сообщение от svu

Другое дело, что могут существовать высокоуровневые бизнес-правила, исключающие некоторые состояния объектов - их стоит реализовывать в бизнес-логике (и, изредка, вообще на фронтенде в виде валидации).

Ты опять путаешь целостность данных с правилами поведения. Это разные понятия, хотя и включающие одно в другое в большинстве случаев.

[tpc]

проблемы ормов и вообще оо подхода в том, что он провоцирует девелопера мыслить не множествами при обработки информации, а объектами. в результе 9 из 10 девелоперов плодит кривой код который на рсубд не одевается ни как, какие бы чудеса не выдумывал оракл.
воротить под этих девелоперов осубд, дело гиблое и по моему уже пройденое в 70х. вот кто-то может сходу рассказать принципиальную разницу между иерархическими субд из 70х и сегодняшними осубд ?

>что Вы скажете о языках, где нет компиляции вообще

лично мне жутко нравиться пхп, когда он на своем месте и отвечает только на валидацию инпута и отрисовку хтмл. опять же 2 конструкции пхп заменяют сотни мегов монстроидальных жавовских фреймворков и кода обвязки и во многом благодаря отсутствию строгой типизации.