Re[27]: Оформление работы с БД в корпоративных приложениях - - Архитектура программного обеспечения

Доброе время суток,

Я 2 года занимаюсь разработкой корпоративных (бизнес) приложений. Как вы знаете, очень большую часть в такого типа приложениях занимает работа с БД. И очень важно правильно ее оформить, потому что при разрастании проекта за несколько тысяч строк (по моему опыту примерно 10000 строк) появляются некоторые проблемы. Можно выделить 2 основные проблемы:

1) Изменение схемы БД. На каком-то уровне оно становится сложным или просто невозможным. Например мы хотим перенести какое-то поле в отдельную таблицу, а в оригинальном поле указывать ID строки из этой новой таблицы. Вполне реальная ситуация что это может понадобится. Но теперь мне приходится перелопачивать сотни запросов в программе и десятки хранимых процедур, а потом молиться что нигде не вывалится скрытый косяк.

2) Смена СУБД. No comments.

Понимаю, что способов оформления работы с БД может быть много. Это может быть тупое написание SQL-кода в обработчике кнопки, это может быть оформление отдельного класса, в котором этот код уже будет записан, это может быть тот же Query Object, и т.д. Вопрос в том какой метод наиболее эффективен и распространен при разработке корпоративных приложений среднего размера (под средним размером я понимаю пару десятков тысяч строк кода написанного вручную и БД из пары десятков таблиц)?

Опишу, как я оформляю работу с БД.

Если какое-то обращение к БД — единичное, т.е. запрос очень специфический и его вызов происходит только в одном месте программы, то я не отделяю его от кода формы, т.е. пишу его прямо в обработчике события или отдельным методом класса формы/контрола, например так:

    private void btnLink_Click(object sender, EventArgs e)
    {
        ...
        MySqlCommand command = new MySqlCommand("LinkSupPaymentToSupInvoice", conn);
        command.CommandType = CommandType.StoredProcedure;
        command.Parameters.Add("?SupInvoiceID_", MySqlDbType.Int32);
                command.Parameters.Add("?SupTransactionsID_", MySqlDbType.Int32).Value = SupTransactionsID;
                for (int i = 0; i < SelectedRows.Length; i++)
                {
                    command.Parameters["?SupInvoiceID_"].Value = Convert.ToInt32(View.GetRowCellValue(SelectedRows[i], ID));
                    command.ExecuteNonQuery();
                }
        ...
    }

Пока писал пример, возник попутный вопрос:
Насколько нужно/ненужно использовать хранимые процедуры/функции? Лично мне это решение зачастую кажется более удобным по нескольким причинам: читабельность кода в программе (просто видим имя процедуры а не длинный SQL запрос и сразу все понимаем), простота изменения (если нужно внести изменения, зачастую изменяем только ХП на сервере а не изменяем что-то в нескольких местах в программе где она используется), ну и для меня не очень важный фактор — производительность.

Ладно, отвлекся, идем дальше.

Если запрос или его модификация должен вызываться из нескольких мест в программе, то я его оформляю в виде статического метода в классе типа CommonFuncs:

    public static double GetPartPrice(int ManufacturerID, int SupplierID, string PartN, MySqlConnection conn)
    {
        try
        {
            MySqlCommand command = new MySqlCommand("GetPartPrice", conn);
            command.CommandType = System.Data.CommandType.StoredProcedure;
            command.Parameters.Add("?ManufacturerID_", MySqlDbType.Int32).Value = ManufacturerID;
            command.Parameters.Add("?SupplierID_", MySqlDbType.Int32).Value = SupplierID;
            command.Parameters.Add("?PartN_", MySqlDbType.VarChar).Value = PartN;
            command.Parameters.Add("?Result", MySqlDbType.Double).Direction = System.Data.ParameterDirection.ReturnValue;
            command.ExecuteNonQuery();
            return Convert.ToDouble(command.Parameters["?Result"].Value);
        }
        catch (Exception ex)
        {
            common.ShowException("An error occurred while trying to get part price from the database.\n\n" +
            "Debug info:\ncommon.cs, GetPartPrice()\n", ex.Message);
            return 0;
        }
    }

Если работа происходит с таблицей (всмысле гридом) обычно стараюсь работать через SelectCommand, UpdateCommand и т.д. класса SqlDataAdapter, типа так:

    ...
    adapterNotScanned.SelectCommand = db.BarcodeSystem.CreateDataAdapterSelectCommand(conn);
    adapterNotScanned.SelectCommand.Parameters.Add("?IsScanned", MySqlDbType.Bit).Value = false;
    adapterNotScanned.SelectCommand.Parameters.Add("?IsPacked", MySqlDbType.Bit).Value = false;
    adapterNotScanned.UpdateCommand = db.BarcodeSystem.NotScannedUpdateCommand(conn);
    adapterNotScanned.TableMappings.Add("parts", "partsNotScanned");
    ...

    // В классе db.BarcodeSystem все выглядит типа так:
    public static MySqlCommand CreateDataAdapterSelectCommand(MySqlConnection conn)
    {
        string strSQL;
        strSQL = "SELECT blablabla FROM parts WHERE Customer = ?Customer AND OrderDebited = true AND " + 
        "OrderInvoiced = false AND IsScanned = ?IsScanned AND IsPacked = ?IsPacked ORDER BY ManufacturerID, PartN";
        MySqlCommand cmd = new MySqlCommand(strSQL, conn);
        return cmd;
    }

Вот в общем-то и все. Так я делаю работу с БД.
Думаю, что мой вопрос и поднятая тема очень важны, и будут очень полезны большому количеству начинающих и средних программистов.
Так что... Направьте на путь истинный?

Заранее большое спасибо. С уважением.

Здравствуйте, Kazna4ey, Вы писали:

K> Я 2 года занимаюсь разработкой корпоративных (бизнес) приложений. Как вы знаете, очень большую часть в такого типа приложениях занимает работа с БД.

Живой пример — Business Logic Toolkit

И начальник заставы поймет меня, и беспечный рыбак простит

Здравствуйте, Kazna4ey, Вы писали:

K>1) Изменение схемы БД. На каком-то уровне оно становится сложным или просто невозможным. Например мы хотим перенести какое-то поле в отдельную таблицу, а в оригинальном поле указывать ID строки из этой новой таблицы. Вполне реальная ситуация что это может понадобится. Но теперь мне приходится перелопачивать сотни запросов в программе и десятки хранимых процедур, а потом молиться что нигде не вывалится скрытый косяк.
K>2) Смена СУБД. No comments.

Это решается введением специального Data Access Layer, находящегося "под" Business Logic Layer и предоставляющего последнему интерфейс в терминах Business Objects (иногда Data Transfer Objects, если логика Business Objects вынесена во внешние манипуляторы).

В этом случае изменение схемы БД, самой БД и т.д. во-первых, локализованно в пределах DAL, а во-вторых, как следствие во-первых, тестирование DAL необходимо и достаточно для тесрирования целостности схемы БД.
Тестирование БД задача, вообще говоря, премерзкая, но если приложение действительно корпоративное, весьма неоходимая. Сложность тестирования DAL заключается не только в выделении test cases, но и подготовке исходных данных. Нередко, для того чтобы протестировать некоторый запрос, необходимо заполнить кучу таблиц.

Забыл сразу написать:

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

Заранее спасибо!

Здравствуйте, Kazna4ey, Вы писали:

K>Доброе время суток,

K> Я 2 года занимаюсь разработкой корпоративных (бизнес) приложений. Как вы знаете, очень большую часть в такого типа приложениях занимает работа с БД. И очень важно правильно ее оформить, потому что при разрастании проекта за несколько тысяч строк (по моему опыту примерно 10000 строк) появляются некоторые проблемы. Можно выделить 2 основные проблемы:

Две вещи звучат странно

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

.

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

public class DataAccessLayer {
   public IList<Order> GetOrdersForDate(DateTime date) {
   }

   public IList<Order> GetOrdersByCustomer(Customer customer) {
   }
}

Фактически у вас такая структура где-то была. А вообще для корпоративных приложений сейчас можно использовать ORM, например Hibernate или iBattis, в зависимости от конкретники задачи. Последний хорошо использоват ьв случае большого количества legacy кода на sql. В случае применения ORM data access objects можно не применять и рассматривать ORM как абстракцию от специфики СУБД. Данный вопрос неодназнеачен и далеко не все согласны отказываться от DAO, только недавно большая дискуссия по сабжу была.

Что ксасается использования хранимок, то тут сколько противников столько же и сторонников. Минусом хранимок явлются как минимум: сложность поддержки, меньшая масштабируемость, зависимость от конкретной СУБД. Для меня этого достаточно , что бы от них отказаться

Здравствуйте, Aviator, Вы писали:

A>Минусом хранимок явлются как минимум: сложность поддержки, меньшая масштабируемость, зависимость от конкретной СУБД.

Это минус по сравнению с чем? По сравнению с вписанными в код SQL запросами?!

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>Минусом хранимок явлются как минимум: сложность поддержки, меньшая масштабируемость, зависимость от конкретной СУБД.
A>Это минус по сравнению с чем? По сравнению с вписанными в код SQL запросами?!
По сравнению с вариантом без привлечения хранимых процедур.

Здравствуйте, Aviator, Вы писали:

A>>>Минусом хранимок явлются как минимум: сложность поддержки, меньшая масштабируемость, зависимость от конкретной СУБД.
A>>Это минус по сравнению с чем? По сравнению с вписанными в код SQL запросами?!
A>По сравнению с вариантом без привлечения хранимых процедур.

ИМХО ХП напротив проще поддерживать потому что:

Прикладной программист знающий только имена таблиц и столбцов не миф. Во-первых, имея уже готовую (постоянно меняющуюся!) БД узнать всё остальное может быть проблемно, во-вторых просто лень.

Про масштабируемость не понял к чему было. Как использование ХП уменьшает масштабируемость системы? Очень интересно послушать, желательно с примерами.

Зависимость от конкретной СУБД будет всегда. Дело даже не в синтаксических различиях диалектов SQL, а в разном объёме предоставляемой функциональности. Система не может быть независимой от СУБД на уровне DAL. Это ИМХО миф и утопия.

Здравствуйте, adontz, Вы писали:

A>

ХП позволяют держать в БД не только данные, но и код управления данными, обеспечивая их целостность (группировку запросов в транзакции и т.п.) на уровне хранения. Естественно, гораздо лучше когда это делает разработчик БД, а не прикладной программист знающий только имена таблиц и столбцов.
Целостность лучше всего обеспечивать на уровне приложения с помощью интуитивно-понятных для пользователя способов. К примеру, на форме необходимые поля должны быть подсвечены и кнопка "OK" должна блокироваться, если они не заполнены. Это намного понятнее, чем сообщение "Error 2422934: Foreign key constraint violation".

БД тут должна работать в качестве "последнего рубежа" обороны — если невалидные данные все-таки прорвались, то хотя бы целостность данных в базе у нас сохранится. Для такой валидации прекрасно подходят триггеры и разные системы валидации в БД.

A> Кроме того, использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными. Это особенно актуально при изменении схемы (добавлении столбца, а то и таблицы). Так же, тестируя ХП на объёмах данных разных порядков можно делать косвенные выводы об асимптоте скорости работы без ручного разбора планов исполнения SQL запросов и прогнозировать наличие узких мест до того как кто-то в них застрял.
Со слоем DAL все точно так же.

A>

Прикладной программист знающий только имена таблиц и столбцов не миф. Во-первых, имея уже готовую (постоянно меняющуюся!) БД узнать всё остальное может быть проблемно, во-вторых просто лень.
Вот поэтому и нужен слой DAL, который изолирует "прикладного программиста" от знания деталей базы данных и дает намного более понятный и приятный объектный интерфейс. Ну и создание DAL можно существенно автоматизировать с помощью ORM.

Здравствуйте, Cyberax, Вы писали:

A>>

ХП пишет тот же, кто разработал схему БД, а значит ХП лучше учитывают наличие или отсутствие индексов. прикладной же программист вставляющий в свой код SQL запросы в лучшем случае прочитал названия таблиц и столбцов.
C>А откуда программист узнает названия ХП, порядок их вызова и какие параметры им передавать?

Если нет документации (кстати почему её нет?), то оттуда же, откуда и имена таблиц — из какого-нибуь Object Browser. Впрочем, если исключить экстрим, и вернутся к документации, то для меня достаточно очевидно, какой из приведённых ниже двух примеров лучше.

Информация о пользователях хранится к таблице Users. Таблица Users содержит столбцы ID, Login, Password, FirstName, LastName. Индексированными являются столбцы ID, Login и Password.

Для доступа к данным о пользователях следует спользовать следующие ХП:

GetUserByCredential(Login, Password)
Возвращает ID, Login, FirstName, LastName

GetUserByID(ID)
Возвращает ID, Login, FirstName, LastName

AddUser(ID, Login, Password, FirstName, LastName)
Добавляет пользователя

ChangeUserPassword(Login, OldPassword, NewPassword)
Меняет пароль пользователя

SetUserFirstName(ID, FirstName)
Задаёт имя пользователя

SetUserLastName(ID, LastName)
Задаёт фамилию пользователя

Программист пользующийся ХП из второго состояния не в состоянии напортачить. Программист пользующийся первым вариантом вполне может отмочить что-то вроде
UPDATE Users SET Password=NewPassword WHERE FirstName='John' AND LastName='Smith'

A>>

ХП позволяют держать в БД не только данные, но и код управления данными, обеспечивая их целостность (группировку запросов в транзакции и т.п.) на уровне хранения. Естественно, гораздо лучше когда это делает разработчик БД, а не прикладной программист знающий только имена таблиц и столбцов.
C>Целостность лучше всего обеспечивать на уровне приложения с помощью интуитивно-понятных для пользователя способов. К примеру, на форме необходимые поля должны быть подсвечены и кнопка "OK" должна блокироваться, если они не заполнены. Это намного понятнее, чем сообщение "Error 2422934: Foreign key constraint violation".
C>БД тут должна работать в качестве "последнего рубежа" обороны — если невалидные данные все-таки прорвались, то хотя бы целостность данных в базе у нас сохранится. Для такой валидации прекрасно подходят триггеры и разные системы валидации в БД.

Я был бы благодарен, если бы ты не только писал, но и читал. Твой ответ абсолютно не в тему. Перечитай моё сообщение ещё раз, особенно отрывок

обеспечивая их целостность (группировку запросов в транзакции и т.п.)

Ты считаешь, что группировку в транзакции надо делать на уровне обработчика событий кнопки ОК?!

A>> Кроме того, использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными. Это особенно актуально при изменении схемы (добавлении столбца, а то и таблицы). Так же, тестируя ХП на объёмах данных разных порядков можно делать косвенные выводы об асимптоте скорости работы без ручного разбора планов исполнения SQL запросов и прогнозировать наличие узких мест до того как кто-то в них застрял.

C>Со слоем DAL все точно так же.

Наличие слоя DAL абсолютно перпендикулярно. Тут обсуждаются примущества наличия ХП перед их отсутвием и напротив. DAL может существовать и отсутствовать и в том и в другом случае.

A>>

Прикладной программист знающий только имена таблиц и столбцов не миф. Во-первых, имея уже готовую (постоянно меняющуюся!) БД узнать всё остальное может быть проблемно, во-вторых просто лень.
C>Вот поэтому и нужен слой DAL, который изолирует "прикладного программиста" от знания деталей базы данных и дает намного более понятный и приятный объектный интерфейс. Ну и создание DAL можно существенно автоматизировать с помощью ORM.

А кто напишет это DAL? Сам возьмётся?

Здравствуйте, adontz, Вы писали:

A>>>>Минусом хранимок явлются как минимум: сложность поддержки, меньшая масштабируемость, зависимость от конкретной СУБД.
A>>>Это минус по сравнению с чем? По сравнению с вписанными в код SQL запросами?!
A>>По сравнению с вариантом без привлечения хранимых процедур.

A>ИМХО ХП напротив проще поддерживать потому что:
Вы когда-нибудь пытались поддерживать ХП?

Я имею в виду более менее большие проекты, а не базы с парой десяткой табличек и 30-40 процедурами.

A>

ХП позволяют держать в БД не только данные, но и код управления данными, обеспечивая их целостность (группировку запросов в транзакции и т.п.) на уровне хранения.
Что чрезвычайно усложняет сопровождение такого проекта, т.к. ХП гораздо сложнее отлаживать и тестировать. О читабельности я вообще молчу.

A>Естественно, гораздо лучше когда это делает разработчик БД, а не прикладной программист знающий только имена таблиц и столбцов.
Потому и используют OR/M. Нету никаких таблиц. Нету никаких столбцов. Есть объекты DAL-уровня со свойствами. Есть соотвествующие объекты BLL уровня с бизнес логикой. Все связи минимальны благодаря IoC-контейнерам (Spring, Castle Windsor и т.п.). Код тщательно документируется. В наличии богатый IntelliSense инструментарий, фреймворки для тестирования типа nUnit с RhinoMocks, средства для автоматического создания документации, мощный отладчик, прекрасная читабельность кода, отсутствие привязки к конкретной БД и минимальная зависимость от схемы БД, высокая масштабируемость.

A>Кроме того, использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными.
Наоборот не позволяет автоматически тестировать. Нет, конечно можно писать тесты для тестирования хранимых процедур, но они редко могут быть полными.

A>Зависимость от конкретной СУБД будет всегда. Дело даже не в синтаксических различиях диалектов SQL, а в разном объёме предоставляемой функциональности. Система не может быть независимой от СУБД на уровне DAL. Это ИМХО миф и утопия.
Да? Какой кошмар...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>

ХП пишет тот же, кто разработал схему БД, а значит ХП лучше учитывают наличие или отсутствие индексов. прикладной же программист вставляющий в свой код SQL запросы в лучшем случае прочитал названия таблиц и столбцов.
C>>А откуда программист узнает названия ХП, порядок их вызова и какие параметры им передавать?
A>Если нет документации (кстати почему её нет?)
А если есть документация по схеме, то откуда тогда программисты знающие только про колонки в базе?

>то оттуда же, откуда и имена таблиц — из какого-нибуь Object Browser. Впрочем, если исключить экстрим, и вернутся к документации, то для меня достаточно очевидно, какой из приведённых ниже двух примеров лучше.
[skip]
A>Программист пользующийся ХП из второго состояния не в состоянии напортачить.
Жуть. У нас куча простых однострочных процедур ТОЛЬКО для одной простенькой сущности, даже без связей. Да еще и нет поддержки оптимистических блокировок.

A>Программист пользующийся первым вариантом вполне может отмочить что-то вроде
A>UPDATE Users SET Password=NewPassword WHERE FirstName='John' AND LastName='Smith'
У меня было бы описано так:

public class User 
{
   private long id,version; //Вообще-то обычно они выделены в базовый класс
   @Column(length=64)
   private String firstName, lastName, login, password;
   
   //Добавим еще для интереса аудит.
   @Requisite(Role.SERVER)
   private List<UserAuditRecord> auditRecords;

   //getter'ы и setter'ы пропускаем по причине их тривиальности.
}

Усё.

Прикладной программист работает с объектами, простые изменения он может персистить вот так:

Session sess=...;
User user=sess.get(User.class, userId);
user.setFirstName("Vasja");
sess.saveOrUpdate(user);

А вот если он попробует так поменять auditRecords — получит в лоб исключением, так как для этого код должен явным образом взять роль "SERVER". Для реального User'а @Requisite будет стоять не на один метод, а на весь класс.

Система еще обеспечит нам автоматическое оптимистическое версирование по полю version.

C>>БД тут должна работать в качестве "последнего рубежа" обороны — если невалидные данные все-таки прорвались, то хотя бы целостность данных в базе у нас сохранится. Для такой валидации прекрасно подходят триггеры и разные системы валидации в БД.
A>Я был бы благодарен, если бы ты не только писал, но и читал. Твой ответ абсолютно не в тему. Перечитай моё сообщение ещё раз, особенно отрывок
A>

A>обеспечивая их целостность (группировку запросов в транзакции и т.п.)

A>Ты считаешь, что группировку в транзакции надо делать на уровне обработчика событий кнопки ОК?!
Да, при открытии формы — начинаем бизнес-транзакцию с оптимистическим версированием, при коммите ее заканчиваем. Механизм работы с транзакциями в БД — отдаем на откуп middleware.

Скажем, у меня это выглядит так:

@Transactional(rollbackFor=Throwable.class)
public class QCManagerBean implements QCManagerRemote
{
    ...
    //Приостанавливает текущую транзакциию на время исполнения метода и начинает новую
    @Transactional(propagation=REQUIRES_NEW)
    public void businessMethod1(...)
    {
    }

    //Обязан выполняться внутри транзакции, но сам ее не начинает
    @Transactional(propagation=MANDATORY)
    public void businessMethod2(...)
    {
    }

    //Автоматически начинает транзакцию, если ее нет.
    public void businessMethod3(...)
    {
    }
}

И я вообще слабо понимаю что ты понимаешь под "группировкой в транзакции". Явный begin/commit из ХП? Так это вообще в морг.

C>>Со слоем DAL все точно так же.
A>Наличие слоя DAL абсолютно перпендикулярно. Тут обсуждаются примущества наличия ХП перед их отсутвием и напротив. DAL может существовать и отсутствовать и в том и в другом случае.
Не перпендикулярно. Имея выделенный слой DAL и XP мы просто будем делать лишнюю работу. Скажем твой пример с пользователем можно точно так же сделать с помощью DAL'а в виде класса UserDAO, с которым и будет работать прикладной программист.

Естественно, за работу с данными минуя DAL — бить ногами.

C>>Вот поэтому и нужен слой DAL, который изолирует "прикладного программиста" от знания деталей базы данных и дает намного более понятный и приятный объектный интерфейс. Ну и создание DAL можно существенно автоматизировать с помощью ORM.
A>А кто напишет это DAL? Сам возьмётся?
Тот программист, который занимается интеграцией с БД. Только не надо сказок, что его нет.

Я прекрасно видел реальные проекты, в которых типА-чистА-крутой-DBA делает все в хранимых процедурах. Обычно кончалось тем, что разработка замедлялась до улиточной скорости из-за того, что DBA приходилось одновременно делать работу от 10 человек (типа: "А мне нужна смена пароля по секретному вопросу!!", "А пароль — case sensetive?" и "Когда же добавят поле 'домен'??").

Здравствуйте, kuj, Вы писали:

A>>ИМХО ХП напротив проще поддерживать потому что:
kuj>Вы когда-нибудь пытались поддерживать ХП?

Я имею в виду более менее большие проекты, а не базы с парой десяткой табличек и 30-40 процедурами.

Поддержкой ХП занимаются программисты БД. Я не такой. Они на моей памяти не жаловались. Мне с ХП работать на порядки проще, чем изучать потроха конкретной схемы.

A>>

ХП пишет тот же, кто разработал схему БД, а значит ХП лучше учитывают наличие или отсутствие индексов. прикладной же программист вставляющий в свой код SQL запросы в лучшем случае прочитал названия таблиц и столбцов.
kuj>В наше время все давно используют различные OR/M.

ORM всего лишь обёртки для мапинга и сопутствующих операций. Если транзакция нужна, а её нет ORM не спасёт. Если делается выборка по неиндексированному столбцу ORM опять таки не спасёт. Спасают, в плане не дают облажатся, именно ХП.

kuj>Что чрезвычайно усложняет сопровождение такого проекта, т.к. ХП гораздо сложнее отлаживать и тестировать. О читабельности я вообще молчу.

Извини, ты с ХП работал вообще?

kuj>Потому и используют OR/M. Нету никаких таблиц. Нету никаких столбцов. Есть объекты DAL-уровня со свойствами. Есть соотвествующие объекты BLL уровня с бизнес логикой. Все связи минимальны благодаря IoC-контейнерам (Spring, Castle Windsor и т.п.). Код тщательно документируется. В наличии богатый IntelliSense инструментарий, фреймворки для тестирования типа nUnit с RhinoMocks, средства для автоматического создания документации, мощный отладчик, прекрасная читабельность кода, отсутствие привязки к конкретной БД и минимальная зависимость от схемы БД, высокая масштабируемость.

Повторюсь. ORM всего лишь обёртки для мапинга и сопутствующих операций. Если транзакция нужна, а её нет ORM не спасёт. Если делается выборка по неиндексированному столбцу ORM опять таки не спасёт. Спасают, в плане не дают облажатся, именно ХП.

Именно тот факт, что ORM являясь очень удобными средствами никак не контроллирующим разработчика и приводит к отказу от ORM в действительно крупных проектах. Когда знакомишься с Hiberbnate первая мысль это ВАУ, потом начинают закрадываться сомнения, а чуть позже задаёшь на форуме вопрос "А без HQL можно?" потому что учёт специфики схемы БД не локализован, а разбросан по проекту. Когда БД растёт вместе с проектом и эта специфика меняется начинаются странные падения производительности "хотя совсем недавно всё работало". Получаем мину замедленного действия. Единственное известно мне исключение — это BLT, но там просто функциональности недостаточно чтоб мины делать (хотя в том что BLT делает, она на высоте).

A>>Кроме того, использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными.
kuj>Наоборот не позволяет автоматически тестировать. Нет, конечно можно писать тесты для тестирования хранимых процедур, но они редко могут быть полными.

Смотря что делают хранимые процедуры. Конечно, если у тебя реализация вида 1запрос-1ХП, то пользы и от ХП мало и от их тестирования.

A>>Зависимость от конкретной СУБД будет всегда. Дело даже не в синтаксических различиях диалектов SQL, а в разном объёме предоставляемой функциональности. Система не может быть независимой от СУБД на уровне DAL. Это ИМХО миф и утопия.
kuj>Да? Какой кошмар...

Если тебе не совсем плевать на производительность, то да. Ты писал приложение, которое должно работать на MSSQL И MySQL? Это очень разные СУБД с разными заскоками. То что бегало на одной, на другой показывало просто УЖАСНУЮ производительность. Например в MySQL нет типа GUID, и если пойти на поводу у лени и хранить GUID'ы в строках, то получим падение производительности в разы. Разбиение на 4 int работало на ура, но никакая ORM не смогла это отобразить, что впрочем и не удивительно.

На самом деле нет никаких великих ORM и OODBMS. Есть реляционные БД со строгой математической теорией от которых никуда не деться именно в связи с огромной строгой математической теорией. Есть традиция ОО программирования от которйо тоже никуда не деться. а ещё есть маркетологи регулярно сулящие чему-нибудь смерть (RDBMS are dead, апплодисместы, хвала новым героям, бабки с Google AdSence ибо скандальное привлекает) и пытающиеся продать очередную серебрянную пулю. Нет ещё такого средства, которое бы эффективно отобразило хранящуюся в памяти объектную модель на данные в РСУБД без пинков и тычков. Когда надоедает пинать и тыкать, наступает просветление и просто делаешь всё руками. Ну или существенную часть.

Здравствуйте, Cyberax, Вы писали:

C>А если есть документация по схеме, то откуда тогда программисты знающие только про колонки в базе?

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

C>Жуть. У нас куча простых однострочных процедур ТОЛЬКО для одной простенькой сущности, даже без связей. Да еще и нет поддержки оптимистических блокировок.

Эти операции тебе понадобятся в любом случае. Никаких лишних сущностей тут нет.

C>

C>public class User 
C>{
C>   private long id,version; //Вообще-то обычно они выделены в базовый класс
C>   @Column(length=64)
C>   private String firstName, lastName, login, password;
   
C>   //Добавим еще для интереса аудит.
C>   @Requisite(Role.SERVER)
C>   private List<UserAuditRecord> auditRecords;

C>   //getter'ы и setter'ы пропускаем по причине их тривиальности.
C>}
C>

C>Усё.

Круто, кто это напишет? Даю намёк, разработчик БД знает только SQL (во всяком случае ему не платят за написание DAL или каких-либо обёрток). Это ситуация в которой я работал не один раз, мне дают голую БД (справедливости ради надо заметить очень хорошо продуманную), над которой надо что-то строить сверху.

C>Да, при открытии формы — начинаем бизнес-транзакцию с оптимистическим версированием, при коммите ее заканчиваем. Механизм работы с транзакциями в БД — отдаем на откуп middleware.

Это совсем другая транзакция, не надо путать тёплое с мягким. Если например, надо статью из категории "Разное" перенести в категорию "Юмор", то разумно на уровне БД в виде ХП реализовать MoveArticle объединяющую DELETE И INSERT в транзакцию, чтобы статья не подвисла без категории (и не оказалась сразу в двух). А вот уже в бизнес-транзакции можешь объединить массовый перенос статей в нечто болеее высокоуровневое, но INSERT И DELETE должны быть объеденены на уровне БД.

C>И я вообще слабо понимаю что ты понимаешь под "группировкой в транзакции".

Да.

C>Явный begin/commit из ХП? Так это вообще в морг.

Здрасьте.

C>Не перпендикулярно. Имея выделенный слой DAL и XP мы просто будем делать лишнюю работу. Скажем твой пример с пользователем можно точно так же сделать с помощью DAL'а в виде класса UserDAO, с которым и будет работать прикладной программист.
C>Естественно, за работу с данными минуя DAL — бить ногами.

DAL и SQL пишут разные люди. Это не два раза одна и та же работа (хотя согласен, что ХП во многом посторяют DAL), это контракт вызова между разными модулями, написанными разными людьми.

A>>А кто напишет это DAL? Сам возьмётся?
C>Тот программист, который занимается интеграцией с БД. Только не надо сказок, что его нет.

Он есть, но это не тот, который разрабатывает БД. И интеграция с БД далеко не основная его работа. Будешь удивлён, но программистов используют согласно языкам, а не задачам. Задача простая — хранить данные, но разделена на две части: DAL на C++/C#/Java/etc. и DB на SQL. Делают их два разных человека, причём тот кто пишет DAL пишёт не только его и читать с утра до вечера хинты SQL'щика (которые то ещё должен написать) на тему "туда не ходи, сюда ходи" как правило достаточно утомительно. Гораздо эффективнее выдать интерфейс БД в виде ХП, которые сами всё расскажут о том как и что можно делать и не дадут сделать "не так".

C>Я прекрасно видел реальные проекты, в которых типА-чистА-крутой-DBA делает все в хранимых процедурах. Обычно кончалось тем, что разработка замедлялась до улиточной скорости из-за того, что DBA приходилось одновременно делать работу от 10 человек (типа: "А мне нужна смена пароля по секретному вопросу!!", "А пароль — case sensetive?" и "Когда же добавят поле 'домен'??").

Извини, это проблема написания ТЗ и управления разработкой, а не ХП

Будет ли пароль case sensitive и будет ли смена пароля по секретному вопросу решается usability специалистами, а не разработчиком БД и уазывается в ТЗ. Остальные читают.
Представь себе DAL для той же задачи хранящий всё в текстовых файлах (никаких ХП). Абсолютно та же ситуация наблюдалась бы. Это отсутствие чёткого ТЗ и только.

Здравствуйте, adontz, Вы писали:

C>>А если есть документация по схеме, то откуда тогда программисты знающие только про колонки в базе?
A>Потому что если есть возможность совершить ошибку, ты хоть миллион предупреждений повесь, всё равно найдётся дурак, который её совершит.
В том числе и DBA в ХП, а эту ошибку потом будут долго отлаживать тупые прикладные пользователи, которые ни разу в жизни не написали ни одного запроса.

C>>Жуть. У нас куча простых однострочных процедур ТОЛЬКО для одной простенькой сущности, даже без связей. Да еще и нет поддержки оптимистических блокировок.
A>Эти операции тебе понадобятся в любом случае. Никаких лишних сущностей тут нет.
Есть. Я могу выкинуть кучу ручного труда с помощью разных автоматических байндеров и валидаторов.

[skip]
C>>Усё.
A>Круто, кто это напишет? Даю намёк, разработчик БД знает только SQL (во всяком случае ему не платят за написание DAL или каких-либо обёрток). Это ситуация в которой я работал не один раз, мне дают голую БД (справедливости ради надо заметить очень хорошо продуманную), над которой надо что-то строить сверху.
Если DBA знает только SQL — то он не сможет понять ТЗ, написаное аналитиком. Так что возможны два варианта:
1. Аналитик дает задание девелоперам, те рисуют черновую схему базы данных (я это делаю прямо в коде, из которого автоматически строится схема). Эта схема с комментариями отдается DBA, который ее оптимизирует (расставляет нужные индексы, ставит дополнительные проверки, может денормализует что-нибудь). Оптимизированая схема отдается обратно девелоперам, которые подправляют под нее код (обычно требуется править совсем немного).
2. Аналитик дает задание DBA. DBA рисует схему и отдает ее программистам. Программисты по схеме строят DAL.

Случай когда тебе дают готовую схему БД означает, что приложение уже скорее всего было написано и работает. Тогда ничего не мешает тебе дать и готовый слой DAL (в виде отдельного модуля). Просто очень часто как раз делают псевдо-DAL на хранимках.

C>>Да, при открытии формы — начинаем бизнес-транзакцию с оптимистическим версированием, при коммите ее заканчиваем. Механизм работы с транзакциями в БД — отдаем на откуп middleware.
A>Это совсем другая транзакция, не надо путать тёплое с мягким. Если например, надо статью из категории "Разное" перенести в категорию "Юмор", то разумно на уровне БД в виде ХП реализовать MoveArticle объединяющую DELETE И INSERT в транзакцию, чтобы статья не подвисла без категории (и не оказалась сразу в двух). А вот уже в бизнес-транзакции можешь объединить массовый перенос статей в нечто болеее высокоуровневое, но INSERT И DELETE должны быть объеденены на уровне БД.
Хороший пример. А если у нас нет операции MoveArticle? Как ты в случае БД

C>>И я вообще слабо понимаю что ты понимаешь под "группировкой в транзакции".
A>Да.
C>>Явный begin/commit из ХП? Так это вообще в морг.
A>Здрасьте.
Досвиданья.

C>>Естественно, за работу с данными минуя DAL — бить ногами.
A>DAL и SQL пишут разные люди. Это не два раза одна и та же работа (хотя согласен, что ХП во многом посторяют DAL), это контракт вызова между разными модулями, написанными разными людьми.
Процедуры DAL в виде selectByLogin/updatePassword замечательно пишут обычные программисты, точнее это все замечательно автоматизируется. Если их переложить на DBA — то он просто завязнет в куче мелких запросов (видел такое собственными глазами далеко не раз), да еще и проблемы с версированием БД начнутся.

На откуп DBA остаются только оптимизации сложных запросов и всякие сложные операции, требующие временных таблиц, километровых запросов и кувырков с переворотами. Вот тут, кстати, ХП как раз вполне подходят.

A>>>А кто напишет это DAL? Сам возьмётся?
C>>Тот программист, который занимается интеграцией с БД. Только не надо сказок, что его нет.
A>Он есть, но это не тот, который разрабатывает БД. И интеграция с БД далеко не основная его работа. Будешь удивлён, но программистов используют согласно языкам, а не задачам. Задача простая — хранить данные, но разделена на две части: DAL на C++/C#/Java/etc. и DB на SQL.
Вот чувствую, что оба делают лишнюю работу.

A>Делают их два разных человека, причём тот кто пишет DAL пишёт не только его и читать с утра до вечера хинты SQL'щика (которые то ещё должен написать) на тему "туда не ходи, сюда ходи" как правило достаточно утомительно. Гораздо эффективнее выдать интерфейс БД в виде ХП, которые сами всё расскажут о том как и что можно делать и не дадут сделать "не так".
Вот ты мне привел пример с XP для операций с User'ом. Не вижу там ни одного нетривиального SQL-оператора, который не смогу написать бы даже студент. Зачем тогда заставлять высококвалифицированного DBA заниматься этой ерундой?

C>>Я прекрасно видел реальные проекты, в которых типА-чистА-крутой-DBA делает все в хранимых процедурах. Обычно кончалось тем, что разработка замедлялась до улиточной скорости из-за того, что DBA приходилось одновременно делать работу от 10 человек (типа: "А мне нужна смена пароля по секретному вопросу!!", "А пароль — case sensetive?" и "Когда же добавят поле 'домен'??").
A>Извини, это проблема написания ТЗ и управления разработкой, а не ХП

Будет ли пароль case sensitive и будет ли смена пароля по секретному вопросу решается usability специалистами, а не разработчиком БД и уазывается в ТЗ. Остальные читают.
Так решается. Вот в середине проекта юзабилист и решил — надо добавить возможность восстановления по секретному вопросу.

A>Представь себе DAL для той же задачи хранящий всё в текстовых файлах (никаких ХП). Абсолютно та же ситуация наблюдалась бы. Это отсутствие чёткого ТЗ и только.
Дело в том, что в таком случае программисты сами смогли бы добавить нужные вещи в DAL и в свои DB. А к DBA потом просто отправить изменения в схеме на review и оптимизацию.

А если мы даем программистам писать/править свои ХП — то тогда они уже у нас скорее всего не полные идиоты, неспособные понять даже простого SQL UPDATE.

Здравствуйте, Cyberax, Вы писали:

C>>>А если есть документация по схеме, то откуда тогда программисты знающие только про колонки в базе?
A>>Потому что если есть возможность совершить ошибку, ты хоть миллион предупреждений повесь, всё равно найдётся дурак, который её совершит.
C>В том числе и DBA в ХП, а эту ошибку потом будут долго отлаживать тупые прикладные пользователи, которые ни разу в жизни не написали ни одного запроса.

Извини, мы не об опечатках. Я ни разу не видел, чтобы разработчик БД сам написал SELECT с кривым планом для БД разработанной им же. Он значит притворяется разработчиком БД если так.

A>>Эти операции тебе понадобятся в любом случае. Никаких лишних сущностей тут нет.
C>Есть. Я могу выкинуть кучу ручного труда с помощью разных автоматических байндеров и валидаторов.

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

C>Если DBA знает только SQL — то он не сможет понять ТЗ, написаное аналитиком. Так что возможны два варианта:

Вполне сможет, если оно написано на уровне Entity-Relations.

C>1. Аналитик дает задание девелоперам, те рисуют черновую схему базы данных (я это делаю прямо в коде, из которого автоматически строится схема). Эта схема с комментариями отдается DBA, который ее оптимизирует (расставляет нужные индексы, ставит дополнительные проверки, может денормализует что-нибудь). Оптимизированая схема отдается обратно девелоперам, которые подправляют под нее код (обычно требуется править совсем немного).

Это порочная практика. Рядовой разработчик никогда не сможет придумать действительно удачную схему хранения данных в БД. DBA должен плясать не от объектной модели, а от ER-диаграммы. В описанном тобой сценарии DAL скорее всего выродится, так как БД будет отображать иерархию объектов, а не хранимые данные. Подкрутить индексы и денормализовать чего-нибудь это далеко не самое главное в разработке схемы. Есть данные которые в реляционную модель, порой, просто не укладываются как есть и их надо преобразовывать до неузнаваемости.

C>2. Аналитик дает задание DBA. DBA рисует схему и отдает ее программистам. Программисты по схеме строят DAL.

Хороший сценарий, мой любимый. Я получаю качественный продукт от человека, не сбитого с толку чьими-то неуместными ОО-идеями.

C>Случай когда тебе дают готовую схему БД означает, что приложение уже скорее всего было написано и работает. Тогда ничего не мешает тебе дать и готовый слой DAL (в виде отдельного модуля). Просто очень часто как раз делают псевдо-DAL на хранимках.

Нет, я всегда по мере возможности настаиваю чтобы БД разрабатывалась в первую очередь.

A>>Это совсем другая транзакция, не надо путать тёплое с мягким. Если например, надо статью из категории "Разное" перенести в категорию "Юмор", то разумно на уровне БД в виде ХП реализовать MoveArticle объединяющую DELETE И INSERT в транзакцию, чтобы статья не подвисла без категории (и не оказалась сразу в двух). А вот уже в бизнес-транзакции можешь объединить массовый перенос статей в нечто болеее высокоуровневое, но INSERT И DELETE должны быть объеденены на уровне БД.
C>Хороший пример. А если у нас нет операции MoveArticle? Как ты в случае БД

Ты кажется не дописал вопрос. Во всяком случае он выглядит недописанным.

C>Процедуры DAL в виде selectByLogin/updatePassword замечательно пишут обычные программисты, точнее это все замечательно автоматизируется. Если их переложить на DBA — то он просто завязнет в куче мелких запросов (видел такое собственными глазами далеко не раз), да еще и проблемы с версированием БД начнутся.

ХЗ, у меня не завязают. Мои выносливее?

C>На откуп DBA остаются только оптимизации сложных запросов и всякие сложные операции, требующие временных таблиц, километровых запросов и кувырков с переворотами. Вот тут, кстати, ХП как раз вполне подходят.

Это DBA-лентяи какие-то. Напрограммил то, что было самому интересно, а на остальное плюнул, путь негры пашут

Безответственно Почему именно — ниже (пометил знаком %).

C>Вот ты мне привел пример с XP для операций с User'ом. Не вижу там ни одного нетривиального SQL-оператора, который не смогу написать бы даже студент. Зачем тогда заставлять высококвалифицированного DBA заниматься этой ерундой?

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

C>А если мы даем программистам писать/править свои ХП — то тогда они уже у нас скорее всего не полные идиоты, неспособные понять даже простого SQL UPDATE.

% (пометка, которую ты ждал)
Проблема в том, что этот простой SQL UPDATE в деномализованной для чего-то там БД может разрушить целостность данных. DBA знает (помнит, записал, пометил для себя крестиком на пальце) что таблица денормализована и что обновив тут, надо ещё подкрутить там (кстати опять транзакция уровня БД, без неё никак). Рядовой программист этого не знает и может напортачить. А раз может, значит обязательно напортачит. Считай это законом Мерфи.

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

Здравствуйте, adontz, Вы писали:
Поддерживать код SQL проще? Не смешите мои тапочки. Если у вас сидит один монстр который с уцтра до вечера фигачит запросы и у которого в голове лежит вся схема базы со всеми хранимками, то я понимаю почему Вы так говорите. А теперь предположитеЮ, что проходят годы, код меняется, дописывается новый. В один прекрасный день происходит непредвиденная ситуация — Ваши монстры SQL уходят, а новым надо уйму времени, что бы осознать какие хранимки что делают и как внести изменение, не поломав что то в другом конце системы. Не говоря уж о том, что бизнес логика должна оперировать понятиями бизнес логиками а не "математическими основами БД". А уж если в один прекрасный день вам предложат мигрировать с MS SQL на Oracle то Вы совсем расстроитесь

Очень странно видеть такую полемику, напоминает религиозные войны программистов на билдере и визуал си. Одним удобно пользоваться неким конструктором, который от них "прячет" (упрощает — кому как нравится) некоторые вещи; другим приятнее сделать всю черновую работу самим и быть увереными, что они не потеряли в производительности и контролируют процесс. В данном случае одни привыкли при работе с базой пользоваться промежуточными автоматизироваными средствами и думают, что это лучший вариант потому что привыкли работать имено в этом русле, другие также привыкли работать через хранимки и считают это вполе нормальным, и работа у них построенна изходя из этой особенности. Если работа организована грамотно, то можно работать в соответсвии с обоими идеями. Если где-то есть просчеты, то в любом случае будут проблемы, какой путь невыбери.
З.Ы.
Странно видеть возглассы о том, что большую бд с кучей хранимок тяжело поддерживать... Хочется задать вопрос, а большой проект с кучей разнородных классов легко подерживать?

Здравствуйте, ilvi, Вы писали:

I>Странно видеть возглассы о том, что большую бд с кучей хранимок тяжело поддерживать... Хочется задать вопрос, а большой проект с кучей разнородных классов легко подерживать?

Код с классами подвергается чёткому структурированию и рефакторингу. Скрипты sql по своей природе плохочитаемы и не особо структурируются.

Здравствуйте, Kazna4ey, Вы писали:

K>1) Изменение схемы БД...

Уже сказали. Либо ORM, либо еще что-то, но обязательно выделенный слой доступа к данным.

K>2) Смена СУБД. No comments.

Это все теория. На практике, например, перейти с SQL Server на Oracle довольно непросто.

K>Вопрос в том какой метод наиболее эффективен и распространен при разработке корпоративных приложений среднего размера (под средним размером я понимаю пару десятков тысяч строк кода написанного вручную и БД из пары десятков таблиц)?

Написание большой части таких запросов прекрасно автоматизируется.

K>Если какое-то обращение к БД — единичное, т.е. запрос очень специфический и его вызов происходит только в одном месте программы, то я не отделяю его от кода формы, т.е. пишу его прямо в обработчике события или отдельным методом класса формы/контрола, например так:

Обрывать руки

K>Пока писал пример, возник попутный вопрос:
K>Насколько нужно/ненужно использовать хранимые процедуры/функции?

Лично мое ХО -- я в общем случае против.

K>Если запрос или его модификация должен вызываться из нескольких мест в программе, то я его оформляю в виде статического метода в классе типа CommonFuncs:

Класс CommonFuncs, я так понимаю, раздувается до совешенно неприличных объемов? Плохо. Статические методы тоже плохо. Хотя бы потому, что код, их использущий, очень тяжело тестировать.

K>Если работа происходит с таблицей (всмысле гридом) обычно стараюсь работать через SelectCommand, UpdateCommand и т.д. класса SqlDataAdapter, типа так:

        strSQL = "SELECT blablabla FROM parts WHERE Customer = ?Customer AND OrderDebited = true AND " + 
        "OrderInvoiced = false AND IsScanned = ?IsScanned AND IsPacked = ?IsPacked ORDER BY ManufacturerID, PartN";

Про запросы в коде см. пункт 1.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Aviator, Вы писали:

A>Поддерживать код SQL проще? Не смешите мои тапочки. Если у вас сидит один монстр который с уцтра до вечера фигачит запросы и у которого в голове лежит вся схема базы со всеми хранимками, то я понимаю почему Вы так говорите. А теперь предположитеЮ, что проходят годы, код меняется, дописывается новый. В один прекрасный день происходит непредвиденная ситуация — Ваши монстры SQL уходят, а новым надо уйму времени, что бы осознать какие хранимки что делают и как внести изменение, не поломав что то в другом конце системы. Не говоря уж о том, что бизнес логика должна оперировать понятиями бизнес логиками а не "математическими основами БД". А уж если в один прекрасный день вам предложат мигрировать с MS SQL на Oracle то Вы совсем расстроитесь

.

То что ты сказал не лишено смысла, но к SQL не имеет решительно никакого отношения. Если мостры SQL непредвиденно уходят, это не прослема SQL или ХП. И если они уходят ни оставив ни капли комментариев, документции и т.п. сколько-нибудь полезной тем, кто пришёл им на замену, то это тоже к SQL имеет слабое отношение.

Здравствуйте, Aviator, Вы писали:

A>Код с классами подвергается чёткому структурированию и рефакторингу. Скрипты sql по своей природе плохочитаемы и не особо структурируются.

Может вы их не так пишете, что их сложнее читать? А то тебя послушать SQL какой-то язык-злодей. А народ активно пользуется, все ошибаются?

Здравствуйте, adontz, Вы писали:

A>>>ИМХО ХП напротив проще поддерживать потому что:
kuj>>Вы когда-нибудь пытались поддерживать ХП?

Я имею в виду более менее большие проекты, а не базы с парой десяткой табличек и 30-40 процедурами.

A>Поддержкой ХП занимаются программисты БД. Я не такой. Они на моей памяти не жаловались. Мне с ХП работать на порядки проще, чем изучать потроха конкретной схемы.

Я не завидую Вашим программистам БД.

A>>>

А посмотреть статистику сервера по запросам и грамотно проставить индексы не судьба? К слову, индексы далеко не всегда являются панацеей и могут даже вредить производительности.

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

kuj>>Что чрезвычайно усложняет сопровождение такого проекта, т.к. ХП гораздо сложнее отлаживать и тестировать. О читабельности я вообще молчу.

A>Извини, ты с ХП работал вообще?

К сожалению. При чем проект среднего размера на ХП был сущей головной болью даже в сравнении с самым сложным и большим проектом, который у нас сейчас есть (7 млн строк кода, 4 тыс. таблиц, более 8 мил. записей) на NHibernate.

kuj>>Потому и используют OR/M. Нету никаких таблиц. Нету никаких столбцов. Есть объекты DAL-уровня со свойствами. Есть соотвествующие объекты BLL уровня с бизнес логикой. Все связи минимальны благодаря IoC-контейнерам (Spring, Castle Windsor и т.п.). Код тщательно документируется. В наличии богатый IntelliSense инструментарий, фреймворки для тестирования типа nUnit с RhinoMocks, средства для автоматического создания документации, мощный отладчик, прекрасная читабельность кода, отсутствие привязки к конкретной БД и минимальная зависимость от схемы БД, высокая масштабируемость.

A>Повторюсь. ORM всего лишь обёртки для мапинга и сопутствующих операций. Если транзакция нужна, а её нет ORM не спасёт. Если делается выборка по неиндексированному столбцу ORM опять таки не спасёт. Спасают, в плане не дают облажатся, именно ХП.

Вы хоть понимаете о чем говорите? Похоже, что не очень.

A>Именно тот факт, что ORM являясь очень удобными средствами никак не контроллирующим разработчика и приводит к отказу от ORM в действительно крупных проектах.

Кто Вам эту чушь сказал?

A> Когда знакомишься с Hiberbnate первая мысль это ВАУ, потом начинают закрадываться сомнения, а чуть позже задаёшь на форуме вопрос "А без HQL можно?" потому что учёт специфики схемы БД не локализован, а разбросан по проекту.

Эээ?

A>Когда БД растёт вместе с проектом и эта специфика меняется начинаются странные падения производительности "хотя совсем недавно всё работало". Получаем мину замедленного действия.

Чушь.

A>Единственное известно мне исключение — это BLT, но там просто функциональности недостаточно чтоб мины делать (хотя в том что BLT делает, она на высоте).

Не знаю, не работал с BLT и не слышал ни об одном более-менее крупном проекте на BLT.

A>>>Кроме того, использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными.
kuj>>Наоборот не позволяет автоматически тестировать. Нет, конечно можно писать тесты для тестирования хранимых процедур, но они редко могут быть полными.

A>Смотря что делают хранимые процедуры. Конечно, если у тебя реализация вида 1запрос-1ХП, то пользы и от ХП мало и от их тестирования.

В том-то и дело, что хранимая процедура это черный ящик. В отличии от тестирования того же CLR — где можно делать mocking объектов. Вы пишете тест для процедуры, которая в свою очередь вызывает еще 20 процедур. В итоге Ваш тест тестирует не (только) эту процедуру, но и остальные 20. Поэтому для модульного тестирования 1 запрос — 1 ХП это вообще идеальный вариант.

A>>>Зависимость от конкретной СУБД будет всегда. Дело даже не в синтаксических различиях диалектов SQL, а в разном объёме предоставляемой функциональности. Система не может быть независимой от СУБД на уровне DAL. Это ИМХО миф и утопия.
kuj>>Да? Какой кошмар...

A>Если тебе не совсем плевать на производительность, то да.

А какие проблемы с производительностью?

A>Ты писал приложение, которое должно работать на MSSQL И MySQL?

Нет, но у нас есть проект, успешно работающий с MS SQL и Oracle.

A>Это очень разные СУБД с разными заскоками. То что бегало на одной, на другой показывало просто УЖАСНУЮ производительность. Например в MySQL нет типа GUID, и если пойти на поводу у лени и хранить GUID'ы в строках, то получим падение производительности в разы. Разбиение на 4 int работало на ура, но никакая ORM не смогла это отобразить, что впрочем и не удивительно.

Ну так и не используйте GUID. Какие проблемы?

A>На самом деле нет никаких великих ORM и OODBMS. Есть реляционные БД со строгой математической теорией от которых никуда не деться именно в связи с огромной строгой математической теорией. Есть традиция ОО программирования от которйо тоже никуда не деться. а ещё есть маркетологи регулярно сулящие чему-нибудь смерть (RDBMS are dead, апплодисместы, хвала новым героям, бабки с Google AdSence ибо скандальное привлекает) и пытающиеся продать очередную серебрянную пулю. Нет ещё такого средства, которое бы эффективно отобразило хранящуюся в памяти объектную модель на данные в РСУБД без пинков и тычков. Когда надоедает пинать и тыкать, наступает просветление и просто делаешь всё руками. Ну или существенную часть.

Ну-ну.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>Может вы их не так пишете, что их сложнее читать? А то тебя послушать SQL какой-то язык-злодей. А народ активно пользуется, все ошибаются?
Это язык написания запросов, адаптированный для написания несложных скриптов. Он не предназначался для написания сложной логики.

Здравствуйте, kuj, Вы писали:

kuj>Вы когда-нибудь пытались поддерживать ХП?

Я имею в виду более менее большие проекты, а не базы с парой десяткой табличек и 30-40 процедурами.
Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.

Здравствуйте, adontz, Вы писали:

A>То что ты сказал не лишено смысла, но к SQL не имеет решительно никакого отношения. Если мостры SQL непредвиденно уходят, это не прослема SQL или ХП. И если они уходят ни оставив ни капли комментариев, документции и т.п. сколько-нибудь полезной тем, кто пришёл им на замену, то это тоже к SQL имеет слабое отношение.

Ты искренне считаешь, что читать код на каком-нибудь transact-sql удобно? Что ковыряться по куче процедур доставляет удовольствие? Что процедурное программирование не менее удобно чем объектное?

Здравствуйте, ilvi, Вы писали:

I>Очень странно видеть такую полемику, напоминает религиозные войны программистов на билдере и визуал си. Одним удобно пользоваться неким конструктором, который от них "прячет" (упрощает — кому как нравится) некоторые вещи; другим приятнее сделать всю черновую работу самим и быть увереными, что они не потеряли в производительности и контролируют процесс.

Есть такое понятие, как сроки, и к сожалению сроки всегда ограничены. Как Вы думаете, зачем был придуман .NET Framework и Java? Можно было бы и на ASM писать... — все контроллировать и быть увереными (быть ли?), что не потеряли производительности и контролируют процесс.

I>В данном случае одни привыкли при работе с базой пользоваться промежуточными автоматизироваными средствами и думают, что это лучший вариант потому что привыкли работать имено в этом русле, другие также привыкли работать через хранимки и считают это вполе нормальным, и работа у них построенна изходя из этой особенности. Если работа организована грамотно, то можно работать в соответсвии с обоими идеями. Если где-то есть просчеты, то в любом случае будут проблемы, какой путь невыбери.
I>З.Ы.
I>Странно видеть возглассы о том, что большую бд с кучей хранимок тяжело поддерживать... Хочется задать вопрос, а большой проект с кучей разнородных классов легко подерживать?

Гораздо легче. Даже, если написано через пень-колоду, все-равно гораздо легче.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, kuj, Вы писали:

kuj>>Вы когда-нибудь пытались поддерживать ХП?

Я имею в виду более менее большие проекты, а не базы с парой десяткой табличек и 30-40 процедурами.
AJD>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.
Интересно, а как у вас организован процесс тестирования? Сидим тыкаем кнопари на формах и ждём что случится?

И вообще, TDD наверно враги прогресса придумали?

Здравствуйте, AndrewJD, Вы писали:

kuj>>Вы когда-нибудь пытались поддерживать ХП?

Я имею в виду более менее большие проекты, а не базы с парой десяткой табличек и 30-40 процедурами.
AJD>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.

Не завидую Вам. Честное слово. Наш проект на ХП с 800 процедур и 180 таблиц это сущая головная боль. Что-то в нем поменять почти не реально. Документации по нем кот наплакал...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, AndrewJD, Вы писали:

kuj>>>Вы когда-нибудь пытались поддерживать ХП?

Я имею в виду более менее большие проекты, а не базы с парой десяткой табличек и 30-40 процедурами.
AJD>>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.

kuj>Не завидую Вам. Честное слово. Наш проект на ХП с 800 процедур и 180 таблиц это сущая головная боль. Что-то в нем поменять почти не реально. Документации по нем кот наплакал...
Просто Вам наверно есть с чем сравнивать, а вот человеку видимо не с чем

. Он искренне думает что лучше не бывает

Здравствуйте, kuj, Вы писали:

AJD>>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.
kuj>Не завидую Вам. Честное слово. Наш проект на ХП с 800 процедур и 180 таблиц это сущая головная боль. Что-то в нем поменять почти не реально. Документации по нем кот наплакал...
Есть мнение что это связано больше с тем как поставлен процес разработки в компании, а не в преимуществе ХП vs запросы

Здравствуйте, adontz, Вы писали:

A>>Поддерживать код SQL проще? Не смешите мои тапочки. Если у вас сидит один монстр который с уцтра до вечера фигачит запросы и у которого в голове лежит вся схема базы со всеми хранимками, то я понимаю почему Вы так говорите. А теперь предположитеЮ, что проходят годы, код меняется, дописывается новый. В один прекрасный день происходит непредвиденная ситуация — Ваши монстры SQL уходят, а новым надо уйму времени, что бы осознать какие хранимки что делают и как внести изменение, не поломав что то в другом конце системы. Не говоря уж о том, что бизнес логика должна оперировать понятиями бизнес логиками а не "математическими основами БД". А уж если в один прекрасный день вам предложат мигрировать с MS SQL на Oracle то Вы совсем расстроитесь

.

A>То что ты сказал не лишено смысла, но к SQL не имеет решительно никакого отношения. Если мостры SQL непредвиденно уходят, это не прослема SQL или ХП. И если они уходят ни оставив ни капли комментариев, документции и т.п. сколько-нибудь полезной тем, кто пришёл им на замену, то это тоже к SQL имеет слабое отношение.

Это как-раз проблема ХП и SQL. Процедуры на T-SQL имеют ужасную читабельность. С PL/SQL чуть лучше, но и они не далеко ушли.

К слову, еще один минус хранимок — доп. нагрузка на сервер, что может стать критичной проблемой при большом количестве одновременно подключенных клиентов.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Aviator, Вы писали:

A>Интересно, а как у вас организован процесс тестирования? Сидим тыкаем кнопари на формах и ждём что случится?

Как обычно, ежедневные автоматические тесты.

A>И вообще, TDD наверно враги прогресса придумали?

TDD — серебрянная пуля?

Здравствуйте, kuj, Вы писали:

kuj>Я не завидую Вашим программистам БД.

Зря. Им хорошо платят и неплохо кормят

A>>ORM всего лишь обёртки для мапинга и сопутствующих операций.
kuj>Вам пора прочитать что такое OR/M.

Ну давай мерятся пиписьками. На вот
http://en.wikipedia.org/wiki/Object-relational_mapping
Что я сказал не так?

A>>Если транзакция нужна, а её нет ORM не спасёт.
kuj>Какие проблемы с транзакциями? OR/M отлично справляются с организацией транзакций.

БД справляется ещё лучше. Нельзя на ORM сваливать всё то, что лень было запрограммировать в БД, так как в результате ты получишь неповоротливую систему.

A>>Если делается выборка по неиндексированному столбцу ORM опять таки не спасёт. Спасают, в плане не дают облажатся, именно ХП.
kuj>Да что Вы говорите...

А посмотреть статистику сервера по запросам и грамотно проставить индексы не судьба?

Ага, то есть предлагаешь отлаживаться на production сервере? Зашибись. А если вдруг выяснится что сама структура хранения неверная и надо не индексами манипулировать, а менять всё нафиг?

kuj>А то время, которые Ваши программисты тратят на поддержку монструозных нечитабельных нетестируемых ХП, можно было бы потратить на более тщательную проработку архитектуры базы и клиентов базы.

Нечитабельные ХП это миф. Нет никаких причин их так писать.

kuj>>>Потому и используют OR/M. Нету никаких таблиц. Нету никаких столбцов. Есть объекты DAL-уровня со свойствами. Есть соотвествующие объекты BLL уровня с бизнес логикой. Все связи минимальны благодаря IoC-контейнерам (Spring, Castle Windsor и т.п.). Код тщательно документируется. В наличии богатый IntelliSense инструментарий, фреймворки для тестирования типа nUnit с RhinoMocks, средства для автоматического создания документации, мощный отладчик, прекрасная читабельность кода, отсутствие привязки к конкретной БД и минимальная зависимость от схемы БД, высокая масштабируемость.

Ты опять употребляешь термин "масштабируемость", хотя кажется не понимаешь его смысла.

kuj>Вы хоть понимаете о чем говорите? Похоже, что не очень.

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

A>>Именно тот факт, что ORM являясь очень удобными средствами никак не контроллирующим разработчика и приводит к отказу от ORM в действительно крупных проектах.
kuj>Кто Вам эту чушь сказал?

Я тебе говорю. Никто в крупном проекте HQL не пользуется, это подходит только для какого-нибудь среднего онлайн-магазина.

A>>Когда БД растёт вместе с проектом и эта специфика меняется начинаются странные падения производительности "хотя совсем недавно всё работало". Получаем мину замедленного действия.
kuj>Чушь.

Ну значит не всречался. Я вот встречался.

A>>Единственное известно мне исключение — это BLT, но там просто функциональности недостаточно чтоб мины делать (хотя в том что BLT делает, она на высоте).
kuj>Не знаю, не работал с BLT и не слышал ни об одном более-менее крупном проекте на BLT.

Ну расширить твой кругозор не сложно. http://www.rsdn.ru/Forum/Info/FAQ.rfd.rfdprojects.aspx

A>>Смотря что делают хранимые процедуры. Конечно, если у тебя реализация вида 1запрос-1ХП, то пользы и от ХП мало и от их тестирования.
kuj>В том-то и дело, что хранимая процедура это черный ящик. В отличии от тестирования того же CLR — где можно делать mocking объектов. Вы пишете тест для процедуры, которая в свою очередь вызывает еще 20 процедур. В итоге Ваш тест тестирует не (только) эту процедуру, но и остальные 20. Поэтому для модульного тестирования 1 запрос — 1 ХП это вообще идеальный вариант.

То что ты написал это полный бред. Получается нельзя тестировать методы классов вызывающие другие методы. Тесты для ХП пишет тот жекто и ХП, для него она не чёрный ящик. А вот тот факт, что ХП чёрный ящик для всех остальных меня радует. Примерно так же как модификатор private. Инкапсуляция... слышал?

A>>Если тебе не совсем плевать на производительность, то да.
kuj>А какие проблемы с производительностью?

Если ты пишешь SQL код работащий под несколько СУБД с минимальными правками, то наверняка не учитываешь особенности СУБД и не пользуешься всеми её возможностями. Как следствие — абсолютно неадекватная производительность.

kuj>Ну так и не используйте GUID. Какие проблемы?
Проблемы в том, что GUIS были нужны

Других проблем нет.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>Код с классами подвергается чёткому структурированию и рефакторингу. Скрипты sql по своей природе плохочитаемы и не особо структурируются.

A>Может вы их не так пишете, что их сложнее читать? А то тебя послушать SQL какой-то язык-злодей. А народ активно пользуется, все ошибаются?

Вы ошибаетесь, думая что "народ активно пользуется".

Ошибаетесь лет так на 7-8.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, AndrewJD, Вы писали:

AJD>>>Успешно поддерживаем и развиваем. Кол-во ХП более 1150, таблиц более 400. ИМО ХП гораздо удобнее.
kuj>>Не завидую Вам. Честное слово. Наш проект на ХП с 800 процедур и 180 таблиц это сущая головная боль. Что-то в нем поменять почти не реально. Документации по нем кот наплакал...
AJD>Есть мнение что это связано больше с тем как поставлен процес разработки в компании, а не в преимуществе ХП vs запросы

ХП vs запросы? О чем Вы?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Aviator, Вы писали:

A>Это язык написания запросов, адаптированный для написания несложных скриптов. Он не предназначался для написания сложной логики.

Никто не говорит о выносе бизнес-логики в SQL. Речь идёт о том, чтобы не делать глупости вида SELECT * FROM everything, а потом разбирать это уровнем выше, потому что "SQL — плохой язык, Java — лучше". То что должно быть запрограммировано на SQL там и должно оставаться.

Здравствуйте, Aviator, Вы писали:

A>Ты искренне считаешь, что читать код на каком-нибудь transact-sql удобно?

Если тот, кто писал код позаботился об удобстве чтения (отступы, вменяемые имена, комментарии гед надо), то да.

A>Что ковыряться по куче процедур доставляет удовольствие?

I LOVE MY JOB! YAHO-O-O-O!

A>Что процедурное программирование не менее удобно чем объектное?

Зависит от контекста. Иногда объекты ни к селу, ни к городу. В реляционной БД я места ООП не вижу.

Здравствуйте, kuj, Вы писали:

kuj>Не завидую Вам. Честное слово. Наш проект на ХП с 800 процедур и 180 таблиц это сущая головная боль. Что-то в нем поменять почти не реально. Документации по нем кот наплакал...

Хранимки причём? Зачем свой единичный негативный опыт распространять на хранимые процедуры вообще?

И вообще, TDD наверно враги прогресса придумали?

Пошутил? Ха-ха. TDD замечательно бывает только на SQL. Ты кажется просто не умеешь тестрировать SQL-код.

Здравствуйте, kuj, Вы писали:

kuj>Это как-раз проблема ХП и SQL. Процедуры на T-SQL имеют ужасную читабельность.

Не имеют. Это твоё личный опыт, вообще говоря это не так.

kuj>К слову, еще один минус хранимок — доп. нагрузка на сервер, что может стать критичной проблемой при большом количестве одновременно подключенных клиентов.

Это бред полнейший.

Здравствуйте, kuj, Вы писали:

kuj>ХП vs запросы? О чем Вы?

О отвоём коде btnLink_Click из первого сообщения, вероятно. Вообще забавно, что человек строящий команду в обработчике кнопки являтся адептом ORM. Что-то тут не так.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>Это язык написания запросов, адаптированный для написания несложных скриптов. Он не предназначался для написания сложной логики.

A>Никто не говорит о выносе бизнес-логики в SQL. Речь идёт о том, чтобы не делать глупости вида SELECT * FROM everything, а потом разбирать это уровнем выше, потому что "SQL — плохой язык, Java — лучше". То что должно быть запрограммировано на SQL там и должно оставаться.
Ы чём заключается обозначенная глупость? Я чё та не понял

Здравствуйте, Aviator, Вы писали:

A>>Никто не говорит о выносе бизнес-логики в SQL. Речь идёт о том, чтобы не делать глупости вида SELECT * FROM everything, а потом разбирать это уровнем выше, потому что "SQL — плохой язык, Java — лучше". То что должно быть запрограммировано на SQL там и должно оставаться.
A>Ы чём заключается обозначенная глупость? Я чё та не понял

.

Ну и о чём тогда говорить, если ты не понимаешь что такое БД и зачем она нужна?

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kuj, Вы писали:

kuj>>Это как-раз проблема ХП и SQL. Процедуры на T-SQL имеют ужасную читабельность.

A>Не имеют. Это твоё личный опыт, вообще говоря это не так.

kuj>>К слову, еще один минус хранимок — доп. нагрузка на сервер, что может стать критичной проблемой при большом количестве одновременно подключенных клиентов.

A>Это бред полнейший.
Не бред, вы с Вашими любимыми хранимками привязаны к одному серверу СУБД. Мне ничего не мешает распаралелить ряд операций по различным серверам.

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, Aviator, Вы писали:

A>>Интересно, а как у вас организован процесс тестирования? Сидим тыкаем кнопари на формах и ждём что случится?

AJD>Как обычно, ежедневные автоматические тесты.

A>>И вообще, TDD наверно враги прогресса придумали?

AJD>TDD — серебрянная пуля?
просто писать юнит тесты на каком нить c# с заглушками намного проще чем организовывать автоматическое тестирование кода совместно с субд

...

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>Интересно, а как у вас организован процесс тестирования? Сидим тыкаем кнопари на формах и ждём что случится?

И вообще, TDD наверно враги прогресса придумали?

A>Пошутил? Ха-ха. TDD замечательно бывает только на SQL. Ты кажется просто не умеешь тестрировать SQL-код.
А ты умеешь?

Здравствуйте, Aviator, Вы писали:

A>>Это бред полнейший.
A>Не бред, вы с Вашими любимыми хранимками привязаны к одному серверу СУБД. Мне ничего не мешает распаралелить ряд операций по различным серверам.

Я распределить нагрузку на уровне СУБД не судьба? СУБД не кластеризуются? Я же говорю, что ты СУБД никогда и не видел толком...

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>>Никто не говорит о выносе бизнес-логики в SQL. Речь идёт о том, чтобы не делать глупости вида SELECT * FROM everything, а потом разбирать это уровнем выше, потому что "SQL — плохой язык, Java — лучше". То что должно быть запрограммировано на SQL там и должно оставаться.
A>>Ы чём заключается обозначенная глупость? Я чё та не понял

.

A>Ну и о чём тогда говорить, если ты не понимаешь что такое БД и зачем она нужна?
Я Вас и не заставляю ничего говорить

Пишите дальше хранимки, пока ещё есть кого заставить их поддерживать

Здравствуйте, Aviator, Вы писали:

A>>Пошутил? Ха-ха. TDD замечательно бывает только на SQL. Ты кажется просто не умеешь тестрировать SQL-код.
A>А ты умеешь?

В мои объязанности не входит их написание, но они есть и, видимо, не с неба упали. Что касается навыка, да я себе достаточно чётко представляю что это такое и как это делать.

Здравствуйте, adontz, Вы писали:

A>>Не бред, вы с Вашими любимыми хранимками привязаны к одному серверу СУБД. Мне ничего не мешает распаралелить ряд операций по различным серверам.
A>Я распределить нагрузку на уровне СУБД не судьба? СУБД не кластеризуются? Я же говорю, что ты СУБД никогда и не видел толком...

Ага а не приходило в голову, что это не самый гибкий подход к построению распределённого приложения?

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>>Пошутил? Ха-ха. TDD замечательно бывает только на SQL. Ты кажется просто не умеешь тестрировать SQL-код.
A>>А ты умеешь?

A>В мои объязанности не входит их написание, но они есть и, видимо, не с неба упали. Что касается навыка, да я себе достаточно чётко представляю что это такое и как это делать.
Ну разъясните будьте любезны нам неразумным

, даже интересно стало. Даже можно с примерами кода.

Здравствуйте, Aviator, Вы писали:

A>>Ну и о чём тогда говорить, если ты не понимаешь что такое БД и зачем она нужна?
A>Я Вас и не заставляю ничего говорить

Пишите дальше хранимки, пока ещё есть кого заставить их поддерживать

.

Пишите дальше SELECT *. Хорошим примером такого способа хранения данных являетс 1С. Вроде бы и в БД всё, но толку от этого никакого. 2процессорный, многоядерный, 4Гб, супер-пупер сервер едва держит 10 клиентских соединений. Вы кажется в эту категорию спешите записаться.

Здравствуйте, Aviator, Вы писали:

A>просто писать юнит тесты на каком нить c# с заглушками намного проще чем организовывать автоматическое тестирование кода совместно с субд

...

Если сравнивать тестирование одной и той же задачи, то абсолютно всё равно.

Здравствуйте, adontz, Вы писали:

kuj>>Я не завидую Вашим программистам БД.

A>Зря. Им хорошо платят и неплохо кормят

Не сомневаюсь. Надбавка за вредность должна быть ну очччччень хорошей.

A>>>ORM всего лишь обёртки для мапинга и сопутствующих операций.
kuj>>Вам пора прочитать что такое OR/M.

A>Ну давай мерятся пиписьками. На вот
A>http://en.wikipedia.org/wiki/Object-relational_mapping
A>Что я сказал не так?
Прочитайте хотя бы http://www.hibernate.org/15.html
ORM это гораздо больше, чем "всего лишь мапинг и сопутствующие операции".

A>>>Если транзакция нужна, а её нет ORM не спасёт.
kuj>>Какие проблемы с транзакциями? OR/M отлично справляются с организацией транзакций.

A>БД справляется ещё лучше. Нельзя на ORM сваливать всё то, что лень было запрограммировать в БД, так как в результате ты получишь неповоротливую систему.

Ликбез: транзакции выполняются на сервере. Только на сервере. Поэтому нет никакого "лучше" / "хуже".
Вот как это делается в Hibernate http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html

A>>>Если делается выборка по неиндексированному столбцу ORM опять таки не спасёт. Спасают, в плане не дают облажатся, именно ХП.
kuj>>Да что Вы говорите...

А посмотреть статистику сервера по запросам и грамотно проставить индексы не судьба?

A>Ага, то есть предлагаешь отлаживаться на production сервере? Зашибись.

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

A>А если вдруг выяснится что сама структура хранения неверная и надо не индексами манипулировать, а менять всё нафиг?

И? Чем Вам тут ХП помогут?

kuj>>А то время, которые Ваши программисты тратят на поддержку монструозных нечитабельных нетестируемых ХП, можно было бы потратить на более тщательную проработку архитектуры базы и клиентов базы.

A>Нечитабельные ХП это миф. Нет никаких причин их так писать.

Их сложно писать не "так" в силу синтаксиса и убогости T-SQL.

kuj>>>>Потому и используют OR/M. Нету никаких таблиц. Нету никаких столбцов. Есть объекты DAL-уровня со свойствами. Есть соотвествующие объекты BLL уровня с бизнес логикой. Все связи минимальны благодаря IoC-контейнерам (Spring, Castle Windsor и т.п.). Код тщательно документируется. В наличии богатый IntelliSense инструментарий, фреймворки для тестирования типа nUnit с RhinoMocks, средства для автоматического создания документации, мощный отладчик, прекрасная читабельность кода, отсутствие привязки к конкретной БД и минимальная зависимость от схемы БД, высокая масштабируемость.

A>Ты опять употребляешь термин "масштабируемость", хотя кажется не понимаешь его смысла.

Да, Вам только кажется.

kuj>>Вы хоть понимаете о чем говорите? Похоже, что не очень.

A>Я говорю о дураках, от которых надо защищатся. Вы, кажется исключительно с высококвалифицированными гениями не делающими ошибок работаете.

Вот именно. Ваш проект на ХП имеет минимум "защиты от дурака". У нас активно применяется TDD, что фактически не возможно было бы, если бы проект был с использованием ХП.

A>>>Именно тот факт, что ORM являясь очень удобными средствами никак не контроллирующим разработчика и приводит к отказу от ORM в действительно крупных проектах.
kuj>>Кто Вам эту чушь сказал?

A>Я тебе говорю. Никто в крупном проекте HQL не пользуется, это подходит только для какого-нибудь среднего онлайн-магазина.

Нда......

A>>>Единственное известно мне исключение — это BLT, но там просто функциональности недостаточно чтоб мины делать (хотя в том что BLT делает, она на высоте).
kuj>>Не знаю, не работал с BLT и не слышал ни об одном более-менее крупном проекте на BLT.

A>Ну расширить твой кругозор не сложно. http://www.rsdn.ru/Forum/Info/FAQ.rfd.rfdprojects.aspx

Это "впечатляет".

A>>>Смотря что делают хранимые процедуры. Конечно, если у тебя реализация вида 1запрос-1ХП, то пользы и от ХП мало и от их тестирования.
kuj>>В том-то и дело, что хранимая процедура это черный ящик. В отличии от тестирования того же CLR — где можно делать mocking объектов. Вы пишете тест для процедуры, которая в свою очередь вызывает еще 20 процедур. В итоге Ваш тест тестирует не (только) эту процедуру, но и остальные 20. Поэтому для модульного тестирования 1 запрос — 1 ХП это вообще идеальный вариант.

A>То что ты написал это полный бред. Получается нельзя тестировать методы классов вызывающие другие методы. Тесты для ХП пишет тот жекто и ХП, для него она не чёрный ящик. А вот тот факт, что ХП чёрный ящик для всех остальных меня радует. Примерно так же как модификатор private. Инкапсуляция... слышал?

Прочитайте чтоли про mocking объектов (RhinoMocks лучшая известная мне реализация) и unit testing, а так же о TDD...
Вы явно не понимаете о чем речь.

A>>>Если тебе не совсем плевать на производительность, то да.
kuj>>А какие проблемы с производительностью?

A>Если ты пишешь SQL код работащий под несколько СУБД с минимальными правками, то наверняка не учитываешь особенности СУБД и не пользуешься всеми её возможностями. Как следствие — абсолютно неадекватная производительность.

Вы кажется не поняли. Я не пишу код под несколько СУБД. Я пишу DAL`ы с использованием (N)Hibernate и Castle ActiveRecord. С проблемами производительности мы пока не сталкивались.

kuj>>Ну так и не используйте GUID. Какие проблемы?
A>Проблемы в том, что GUIS были нужны

Других проблем нет.

Кстати, а при чем тут MySql? MySQL это вообще СУБД для других целей и мало подходит для "БД в корпоративных приложениях".

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>ХП vs запросы? О чем Вы?
Хм. А о чем ветка? Разве не о преимуществах/недостатках использования ХП?

Здравствуйте, Aviator, Вы писали:

A>>Я распределить нагрузку на уровне СУБД не судьба? СУБД не кластеризуются? Я же говорю, что ты СУБД никогда и не видел толком...
A>Ага а не приходило в голову, что это не самый гибкий подход к построению распределённого приложения?

Как раз это самый гибкий, рабить BL и DAL на разные tier, сделать BL максимально stateless (по крайней мере не кешируещим) и получить щасте. BL для кластеризации начитает хватать обычного NLB, DAL кластеризуется средствами БД. Получаем двухуровневую систему кластеров. В каждый уровень можно досбавлять кластеры по мере необходимости. Весьма гибко.

Здравствуйте, adontz, Вы писали:

kuj>>ХП vs запросы? О чем Вы?

A>О отвоём коде btnLink_Click из первого сообщения, вероятно. Вообще забавно, что человек строящий команду в обработчике кнопки являтся адептом ORM. Что-то тут не так.

О каком-таком моем коде? Окститесь.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>Не завидую Вам. Честное слово. Наш проект на ХП с 800 процедур и 180 таблиц это сущая головная боль. Что-то в нем поменять почти не реально. Документации по нем кот наплакал...

A>Хранимки причём? Зачем свой единичный негативный опыт распространять на хранимые процедуры вообще?

При том, что ХП сложно документировать, сложно читать, сложно тестировать, сложно отлаживать.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>Ты искренне считаешь, что читать код на каком-нибудь transact-sql удобно?

>>Если тот, кто писал код позаботился об удобстве чтения (отступы, вменяемые имена, комментарии гед надо), то да.
Да отступы и комментарии — это конечно залог читаемости кода

.

A>>Что ковыряться по куче процедур доставляет удовольствие?
A>I LOVE MY JOB! YAHO-O-O-O!
Ну учитывая что вы заставляете этим заниматься кого то другого вполне так оно и есть

A>>Что процедурное программирование не менее удобно чем объектное?

A>Зависит от контекста. Иногда объекты ни к селу, ни к городу. В реляционной БД я места ООП не вижу.
Реляционная БД — это всего лишь хранилище данных, Вы путаете задачу хранения и обработки. Споры вызывает то, что Вы хотите на хранилище возложить ещё и функции обработки. Разработчика бизнес логики в большинстве случев вообще не интересует какая там субд и как она сохраняет, он оперирует доменными объектами.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>>Ну и о чём тогда говорить, если ты не понимаешь что такое БД и зачем она нужна?
A>>Я Вас и не заставляю ничего говорить

Пишите дальше хранимки, пока ещё есть кого заставить их поддерживать

.

A>Пишите дальше SELECT *. Хорошим примером такого способа хранения данных являетс 1С. Вроде бы и в БД всё, но толку от этого никакого. 2процессорный, многоядерный, 4Гб, супер-пупер сервер едва держит 10 клиентских соединений. Вы кажется в эту категорию спешите записаться.
Давно уже применяю ORM чего желал бы и Вашим специалистам

Здравствуйте, AndrewJD, Вы писали:

A>>Интересно, а как у вас организован процесс тестирования? Сидим тыкаем кнопари на формах и ждём что случится?

AJD>Как обычно, ежедневные автоматические тесты.
Можно пример?

A>>И вообще, TDD наверно враги прогресса придумали?

AJD>TDD — серебрянная пуля?
Посеребренная.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

A>>Ну давай мерятся пиписьками. На вот
A>>http://en.wikipedia.org/wiki/Object-relational_mapping
A>>Что я сказал не так?
kuj>Прочитайте хотя бы http://www.hibernate.org/15.html
kuj>ORM это гораздо больше, чем "всего лишь мапинг и сопутствующие операции".

Это не ORM гораздо больше, это конкретно Hiberbate гораздо больше. Ты что-то кроме Hibernate видел или как?

A>>БД справляется ещё лучше. Нельзя на ORM сваливать всё то, что лень было запрограммировать в БД, так как в результате ты получишь неповоротливую систему.
kuj>Ликбез: транзакции выполняются на сервере. Только на сервере. Поэтому нет никакого "лучше" / "хуже".

Мысль что Hibernate и БД могут работать на разных серверах в голову не приходила?

A>>Ага, то есть предлагаешь отлаживаться на production сервере? Зашибись.

A>>А если вдруг выяснится что сама структура хранения неверная и надо не индексами манипулировать, а менять всё нафиг?
kuj>И? Чем Вам тут ХП помогут?

ORM тут тоже не помогают. А ХП как раз могут помочь, так как они чёрный ящик и с высокой вероятностью DAL претерпит не очень большие изменения.

kuj>Их сложно писать не "так" в силу синтаксиса и убогости T-SQL.

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

kuj>Вот именно. Ваш проект на ХП имеет минимум "защиты от дурака". У нас активно применяется TDD, что фактически не возможно было бы, если бы проект был с использованием ХП.

TDD проверяет корректность работы, а не эффективность.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>просто писать юнит тесты на каком нить c# с заглушками намного проще чем организовывать автоматическое тестирование кода совместно с субд

...

A>Если сравнивать тестирование одной и той же задачи, то абсолютно всё равно.
Вы это серьёзно сказали? Вы вообще представляете процесс тестирования на уровне юнит тестов?

Здравствуйте, adontz, Вы писали:

A>>просто писать юнит тесты на каком нить c# с заглушками намного проще чем организовывать автоматическое тестирование кода совместно с субд

...

A>Если сравнивать тестирование одной и той же задачи, то абсолютно всё равно.

Вы хоть понимаете о чем говорите??

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:
A>То что ты сказал не лишено смысла, но к SQL не имеет решительно никакого отношения. Если мостры SQL непредвиденно уходят, это не прослема SQL или ХП. И если они уходят ни оставив ни капли комментариев, документции и т.п. сколько-нибудь полезной тем, кто пришёл им на замену, то это тоже к SQL имеет слабое отношение.
Зато к SQL имеет 100% отношение тот факт, что нет надежного способа определить, сломало ли добавление новой колонки в таблицу какую-то из хранимок или нет. Напомню, что для современных языков высокого уровня есть средства рефакторинга, а для SQL — нету. Так и живут десятилетиями опечатки в именах колонок.
В этом смысле ORM намного лучше. А Linq вообще рвет всех как тазик тузика.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>>Я распределить нагрузку на уровне СУБД не судьба? СУБД не кластеризуются? Я же говорю, что ты СУБД никогда и не видел толком...
A>>Ага а не приходило в голову, что это не самый гибкий подход к построению распределённого приложения?

A>Как раз это самый гибкий, рабить BL и DAL на разные tier, сделать BL максимально stateless (по крайней мере не кешируещим) и получить щасте. BL для кластеризации начитает хватать обычного NLB, DAL кластеризуется средствами БД. Получаем двухуровневую систему кластеров. В каждый уровень можно досбавлять кластеры по мере необходимости. Весьма гибко.
Это Вам часом не какой-нить распространитель MS SQL сказал?

Здравствуйте, Sinclair, Вы писали:

S>Зато к SQL имеет 100% отношение тот факт, что нет надежного способа определить, сломало ли добавление новой колонки в таблицу какую-то из хранимок или нет. Напомню, что для современных языков высокого уровня есть средства рефакторинга, а для SQL — нету. Так и живут десятилетиями опечатки в именах колонок.

Ты о чём? ХП с опечатками не компилируются

Здравствуйте, Aviator, Вы писали:

A>>>Что процедурное программирование не менее удобно чем объектное?

A>>Зависит от контекста. Иногда объекты ни к селу, ни к городу. В реляционной БД я места ООП не вижу.
A>Реляционная БД — это всего лишь хранилище данных, Вы путаете задачу хранения и обработки. Споры вызывает то, что Вы хотите на хранилище возложить ещё и функции обработки. Разработчика бизнес логики в большинстве случев вообще не интересует какая там субд и как она сохраняет, он оперирует доменными объектами.

Вот-вот! Вот этого-то ты и не понимаешь! Народ пишет мегамощные оптимизаторы, реализует сложнешие алгоритмы, а ты телевозир используешь как тумбочку. БД — это НЕ только хранилище данных, но и обработчик низкого уровня.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>>>Что процедурное программирование не менее удобно чем объектное?

A>>>Зависит от контекста. Иногда объекты ни к селу, ни к городу. В реляционной БД я места ООП не вижу.
A>>Реляционная БД — это всего лишь хранилище данных, Вы путаете задачу хранения и обработки. Споры вызывает то, что Вы хотите на хранилище возложить ещё и функции обработки. Разработчика бизнес логики в большинстве случев вообще не интересует какая там субд и как она сохраняет, он оперирует доменными объектами.

A>Вот-вот! Вот этого-то ты и не понимаешь! Народ пишет мегамощные оптимизаторы, реализует сложнешие алгоритмы, а ты телевозир используешь как тумбочку. БД — это НЕ только хранилище данных, но и обработчик низкого уровня.
Если бы Вы такое произнесли в году там 97, это было бы сильное высказывание, а вот в 2007ом стараются максимально абстрагироваться от конкретики СУБД

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kuj, Вы писали:

A>>>Ну давай мерятся пиписьками. На вот
A>>>http://en.wikipedia.org/wiki/Object-relational_mapping
A>>>Что я сказал не так?
kuj>>Прочитайте хотя бы http://www.hibernate.org/15.html
kuj>>ORM это гораздо больше, чем "всего лишь мапинг и сопутствующие операции".

A>Это не ORM гораздо больше, это конкретно Hiberbate гораздо больше.
Hibernate это не ORM?
A>Ты что-то кроме Hibernate видел или как?
Видел. И даже работал. Был проект на LLBLGen Pro на предыдущем месте работы. Все современные ORM имеют примерно одинаковую функциональность. Hibernate в силу ряда причин самая популярная. Вот и все.

A>>>БД справляется ещё лучше. Нельзя на ORM сваливать всё то, что лень было запрограммировать в БД, так как в результате ты получишь неповоротливую систему.
kuj>>Ликбез: транзакции выполняются на сервере. Только на сервере. Поэтому нет никакого "лучше" / "хуже".

A>Мысль что Hibernate и БД могут работать на разных серверах в голову не приходила?

Ээээээээ?

Вы ДЕЙСТВИТЕЛЬНО на столько не разбираетесь в предмете спора? Смешно.

A>>>Ага, то есть предлагаешь отлаживаться на production сервере? Зашибись.

A>>>А если вдруг выяснится что сама структура хранения неверная и надо не индексами манипулировать, а менять всё нафиг?
kuj>>И? Чем Вам тут ХП помогут?

A>ORM тут тоже не помогают. А ХП как раз могут помочь, так как они чёрный ящик и с высокой вероятностью DAL претерпит не очень большие изменения.

Вы потратите в десять раз больше времени на то, чтоб поправить, отладить и протестировать процедуры.

kuj>>Их сложно писать не "так" в силу синтаксиса и убогости T-SQL.

A>Ещё один миф. SQL декларативный язык, это уже обеспечивает хорошую читаемость.

Вы разницу между T-SQL и SQL вообще понимаете?

kuj>>Вот именно. Ваш проект на ХП имеет минимум "защиты от дурака". У нас активно применяется TDD, что фактически не возможно было бы, если бы проект был с использованием ХП.

A>TDD проверяет корректность работы, а не эффективность.

Для проверки "эффективности" есть профайлеры. К тому же, TDD ничего не проверяет. TDD это методика программирования по принципу "сначала пишем тест, потом пишем код".

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Aviator, Вы писали:

A>>Вот-вот! Вот этого-то ты и не понимаешь! Народ пишет мегамощные оптимизаторы, реализует сложнешие алгоритмы, а ты телевозир используешь как тумбочку. БД — это НЕ только хранилище данных, но и обработчик низкого уровня.
A>Если бы Вы такое произнесли в году там 97, это было бы сильное высказывание, а вот в 2007ом стараются максимально абстрагироваться от конкретики СУБД

Здравствуйте, kuj, Вы писали:

kuj>>>Ликбез: транзакции выполняются на сервере. Только на сервере. Поэтому нет никакого "лучше" / "хуже".
A>>Мысль что Hibernate и БД могут работать на разных серверах в голову не приходила?
kuj>Ээээээээ?

Вы ДЕЙСТВИТЕЛЬНО на столько не разбираетесь в предмете спора? Смешно.

Видишь ли, Hibernate как правило наботает в tier бизнесс-логики. У этого подхода есть преимущества в администрировании. Так что чего т так удивился я не особо понял.

A>>ORM тут тоже не помогают. А ХП как раз могут помочь, так как они чёрный ящик и с высокой вероятностью DAL претерпит не очень большие изменения.
kuj>Вы потратите в десять раз больше времени на то, чтоб поправить, отладить и протестировать процедуры.

Миф.

kuj>>>Их сложно писать не "так" в силу синтаксиса и убогости T-SQL.
A>>Ещё один миф. SQL декларативный язык, это уже обеспечивает хорошую читаемость.
kuj>Вы разницу между T-SQL и SQL вообще понимаете?

SELECT * FROM table это декларативное предложение. SQL — декларативный язык. Ты в курсе что такое декларативный язык? Нет? Тогда, иди почитай.

A>>TDD проверяет корректность работы, а не эффективность.
kuj>Для проверки "эффективности" есть профайлеры. К тому же, TDD ничего не проверяет. TDD это методика программирования по принципу "сначала пишем тест, потом пишем код".

ОК, "TDD позволяет проверить..." В любом случае вероятность уронить производительность системы гораздо выше, когда к БД обращаются как попало.

Здравствуйте, adontz, Вы писали:

S>>Зато к SQL имеет 100% отношение тот факт, что нет надежного способа определить, сломало ли добавление новой колонки в таблицу какую-то из хранимок или нет. Напомню, что для современных языков высокого уровня есть средства рефакторинга, а для SQL — нету. Так и живут десятилетиями опечатки в именах колонок.

A>Ты о чём? ХП с опечатками не компилируются

Человек говорит Вам о рефакторинге и об опечатках в колонках. Когда у вас сотни процедур с таким вот именем колонки жестко прописанным в каждой процедуре...
В случае с OR/M, поменяв имя колонки в базе, мне достаточно поменять его всего-лишь раз в файле мэпинга, а Вам придется перелопачивать все сотни процедур да еще и без стредств рефакторинга.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kuj, Вы писали:

kuj>>>>Ликбез: транзакции выполняются на сервере. Только на сервере. Поэтому нет никакого "лучше" / "хуже".
A>>>Мысль что Hibernate и БД могут работать на разных серверах в голову не приходила?
kuj>>Ээээээээ?

Вы ДЕЙСТВИТЕЛЬНО на столько не разбираетесь в предмете спора? Смешно.

A>Видишь ли, Hibernate как правило наботает в tier бизнесс-логики. У этого подхода есть преимущества в администрировании. Так что чего т так удивился я не особо понял.
Сам то понял что написал?

A>>>ORM тут тоже не помогают. А ХП как раз могут помочь, так как они чёрный ящик и с высокой вероятностью DAL претерпит не очень большие изменения.
kuj>>Вы потратите в десять раз больше времени на то, чтоб поправить, отладить и протестировать процедуры.
A>Миф.
Я понял, что вы не тестируете, поэтому у вас всё быстро

kuj>>>>Их сложно писать не "так" в силу синтаксиса и убогости T-SQL.
A>>>Ещё один миф. SQL декларативный язык, это уже обеспечивает хорошую читаемость.
kuj>>Вы разницу между T-SQL и SQL вообще понимаете?
A>SELECT * FROM table это декларативное предложение. SQL — декларативный язык. Ты в курсе что такое декларативный язык? Нет? Тогда, иди почитай.
Это sql, мы говорим о T-SQL и хранимках. типичный код хранимки не декларативный и представляет из себя жёское процедурное программирование

A>>>TDD проверяет корректность работы, а не эффективность.
kuj>>Для проверки "эффективности" есть профайлеры. К тому же, TDD ничего не проверяет. TDD это методика программирования по принципу "сначала пишем тест, потом пишем код".

A>ОК, "TDD позволяет проверить..." В любом случае вероятность уронить производительность системы гораздо выше, когда к БД обращаются как попало.

Что понимается по как попало объясните пожалуйста, а то я начинаю терять нить изложения

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, adontz, Вы писали:

S>>>Зато к SQL имеет 100% отношение тот факт, что нет надежного способа определить, сломало ли добавление новой колонки в таблицу какую-то из хранимок или нет. Напомню, что для современных языков высокого уровня есть средства рефакторинга, а для SQL — нету. Так и живут десятилетиями опечатки в именах колонок.

A>>Ты о чём? ХП с опечатками не компилируются

kuj>Человек говорит Вам о рефакторинге и об опечатках в колонках. Когда у вас сотни процедур с таким вот именем колонки жестко прописанным в каждой процедуре...
kuj>В случае с OR/M, поменяв имя колонки в базе, мне достаточно поменять его всего-лишь раз в файле мэпинга, а Вам придется перелопачивать все сотни процедур да еще и без стредств рефакторинга.
Подозреваю, что человек не знает что такое рефакторинг так что Ваш довод для него пустой звук

Здравствуйте, adontz, Вы писали:

kuj>>>>Ликбез: транзакции выполняются на сервере. Только на сервере. Поэтому нет никакого "лучше" / "хуже".
A>>>Мысль что Hibernate и БД могут работать на разных серверах в голову не приходила?
kuj>>Ээээээээ?

Вы ДЕЙСТВИТЕЛЬНО на столько не разбираетесь в предмете спора? Смешно.

A>Видишь ли, Hibernate как правило наботает в tier бизнесс-логики.
Где-где?

Бизнес-логика никакого. Абсолютно никакого отношения к Hibernate не имеет.

A>У этого подхода есть преимущества в администрировании. Так что чего т так удивился я не особо понял.
"Hibernate и БД могут работать на разных серверах"

A>>>ORM тут тоже не помогают. А ХП как раз могут помочь, так как они чёрный ящик и с высокой вероятностью DAL претерпит не очень большие изменения.
kuj>>Вы потратите в десять раз больше времени на то, чтоб поправить, отладить и протестировать процедуры.
A>Миф.
С такой категоричностью не поспоришь... Ну что ж, Вы поймете со временем и с опытом...

kuj>>>>Их сложно писать не "так" в силу синтаксиса и убогости T-SQL.
A>>>Ещё один миф. SQL декларативный язык, это уже обеспечивает хорошую читаемость.
kuj>>Вы разницу между T-SQL и SQL вообще понимаете?

A>SELECT * FROM table это декларативное предложение. SQL — декларативный язык. Ты в курсе что такое декларативный язык? Нет? Тогда, иди почитай.
Я в курсе что такое декларативный язык. Только при чем тут SQL, когда речь о T-SQL. Вы ДЕЙСТВИТЕЛЬНО не понимаете? Нда.......

A>>>TDD проверяет корректность работы, а не эффективность.
kuj>>Для проверки "эффективности" есть профайлеры. К тому же, TDD ничего не проверяет. TDD это методика программирования по принципу "сначала пишем тест, потом пишем код".

A>ОК, "TDD позволяет проверить..." В любом случае вероятность уронить производительность системы гораздо выше, когда к БД обращаются как попало.

Нда.....

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:
A>Ты о чём? ХП с опечатками не компилируются

Я о полях с именем типа ProdactID.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, adontz, Вы писали:

A>SQL — декларативный язык.

Кстати говоря, SQL это ни разу не декларативный язык. SQL это информационно-логический язык и по-сути он не является языком программирования. SQL это структурированный язык запросов.
Декларативный язык это, например, Prolog.

К слову, .NET языки имеют куда больше декларативных элементов. В случае того же ActiveRecord мэпинг выполняется декларативно в виде атрибутов:

namespace BlogSample
{
    using System;
    using Castle.ActiveRecord;

    [ActiveRecord]
    public class User : ActiveRecordBase<User>
    {
        private int id;
        private string username;
        private string password;
        
        public User() 
        {
        }
        
        public User(string username, string password)
        {
            this.username = username;
            this.password = password;
        }

        [PrimaryKey]
        public int Id
        {
            get { return id; }
            set { id = value; }
        }

        [Property]
        public string Username
        {
            get { return username; }
            set { username = value; }
        }

        [Property]
        public string Password
        {
            get { return password; }
            set { password = value; }
        }
    }
}

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Ну и о чём тогда говорить, если ты не понимаешь что такое БД и зачем она нужна?
A>>Я Вас и не заставляю ничего говорить

Пишите дальше хранимки, пока ещё есть кого заставить их поддерживать

.

A>Пишите дальше SELECT *.
Наоборот тут речь о том, чтоб генерацией SQL-запросов занимался Hibernate (или т.п.), который прекрасно с этой задачей справляется, и в запросах, генерируемых Hibernate, Вы не увидете "*".

A> Хорошим примером такого способа хранения данных являетс 1С. Вроде бы и в БД всё, но толку от этого никакого. 2процессорный, многоядерный, 4Гб, супер-пупер сервер едва держит 10 клиентских соединений. Вы кажется в эту категорию спешите записаться.

Очень удачно Вы привели 1С, как пример "неудачной системы".

Называется: ежики плакали, кололись, но продолжали жрать кактус.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>Ну давай мерятся пиписьками. На вот
A>http://en.wikipedia.org/wiki/Object-relational_mapping
A>Что я сказал не так?
Видимо, не использовал Hibernate в реальности

Кэш второго уровня там часто ускоряет работу в десятки раз, я об этом тут даже писал.

A>>>Если транзакция нужна, а её нет ORM не спасёт.
kuj>>Какие проблемы с транзакциями? OR/M отлично справляются с организацией транзакций.
A>БД справляется ещё лучше. Нельзя на ORM сваливать всё то, что лень было запрограммировать в БД, так как в результате ты получишь неповоротливую систему.
Ты слово "организацией" не заметил? В Hibernate там для этого так вообще инструментов БОЛЬШЕ, чем в голом SQL. В частности, есть очень полезная автоматическая оптимистическая блокировка с поддержкой detach/attach для сессионных объектов, которую руками писать — только ошибки плодить (так как ее обязательно будут забывать использовать).

A>>>Если делается выборка по неиндексированному столбцу ORM опять таки не спасёт. Спасают, в плане не дают облажатся, именно ХП.
kuj>>Да что Вы говорите...

А посмотреть статистику сервера по запросам и грамотно проставить индексы не судьба?
A>Ага, то есть предлагаешь отлаживаться на production сервере? Зашибись. А если вдруг выяснится что сама структура хранения неверная и надо не индексами манипулировать, а менять всё нафиг?
Нормальность (во всех смыслах) схемы ПРЕКРАСНО можно проверить вообще "на глаз". Если DBA не замечает таких явных косяков — то его увольнять надо. Расстановка неочевидных индексов, действительно, лучше всего делается по результатам нагрузочного тестирования (на тестовом сервере, не на production!).

Другое дело, когда все было изначально неправильно спроектировано из-за неправильного моделирования предметной области. Но тут хранимые процедуры будут только в минусе — код с нормальным DAL'ом рефакторить легче.

kuj>>А то время, которые Ваши программисты тратят на поддержку монструозных нечитабельных нетестируемых ХП, можно было бы потратить на более тщательную проработку архитектуры базы и клиентов базы.
A>Нечитабельные ХП это миф. Нет никаких причин их так писать.
Они сами так получаются. Причем, если программисты читают ХП, то у нас теряется один из мотивов их внедрения — разделения труда между разработчиками БД и приложения.

A>>>Именно тот факт, что ORM являясь очень удобными средствами никак не контроллирующим разработчика и приводит к отказу от ORM в действительно крупных проектах.
kuj>>Кто Вам эту чушь сказал?
A>Я тебе говорю. Никто в крупном проекте HQL не пользуется, это подходит только для какого-нибудь среднего онлайн-магазина.
???
Ты знаешь такой меееелкий тормозной проект как Google Adwords или Google Blogs? Так вот, их не существует, так как Hibernate в них используется.

A>>>Когда БД растёт вместе с проектом и эта специфика меняется начинаются странные падения производительности "хотя совсем недавно всё работало". Получаем мину замедленного действия.
kuj>>Чушь.
A>Ну значит не всречался. Я вот встречался.
Чушь, чушь. Такие "падения производительности" были бы и с SQL, так как Hibernate не делает ничего магического.

A>>>Единственное известно мне исключение — это BLT, но там просто функциональности недостаточно чтоб мины делать (хотя в том что BLT делает, она на высоте).
kuj>>Не знаю, не работал с BLT и не слышал ни об одном более-менее крупном проекте на BLT.
A>Ну расширить твой кругозор не сложно. http://www.rsdn.ru/Forum/Info/FAQ.rfd.rfdprojects.aspx
http://hibernate.org/113.html
http://hibernate.org/290.html
(и это мааааааааааленькая часть общего количества)

A>То что ты написал это полный бред. Получается нельзя тестировать методы классов вызывающие другие методы. Тесты для ХП пишет тот жекто и ХП, для него она не чёрный ящик. А вот тот факт, что ХП чёрный ящик для всех остальных меня радует. Примерно так же как модификатор private. Инкапсуляция... слышал?
Открой для себя mock objects

Я сейчас вообще слабо понимаю как без них тестировал раньше.

A>>>Если тебе не совсем плевать на производительность, то да.
kuj>>А какие проблемы с производительностью?
A>Если ты пишешь SQL код работащий под несколько СУБД с минимальными правками, то наверняка не учитываешь особенности СУБД и не пользуешься всеми её возможностями. Как следствие — абсолютно неадекватная производительность.
Так если тормозит — втыкаем вместо HQL-запроса оптимизированый SQL. Какие проблемы-то? Hibernate позволяет замечательно использовать нативный SQL. Только вот нужно это всего в процентах случаев.

Здравствуйте, adontz, Вы писали:

A>>Что процедурное программирование не менее удобно чем объектное?

A>Зависит от контекста. Иногда объекты ни к селу, ни к городу. В реляционной БД я места ООП не вижу.

Конечно не видете. Как же Вам видеть, если Вы вообще не понимаете о чем речь...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Вот-вот! Вот этого-то ты и не понимаешь! Народ пишет мегамощные оптимизаторы, реализует сложнешие алгоритмы, а ты телевозир используешь как тумбочку. БД — это НЕ только хранилище данных, но и обработчик низкого уровня.
A>>Если бы Вы такое произнесли в году там 97, это было бы сильное высказывание, а вот в 2007ом стараются максимально абстрагироваться от конкретики СУБД

. ORM стновится де факто стандартом разработки корпоративных приложений, linq уже близок к релизному варианту, веб страницы активно пишут на компилируемых яъзыках, скрипты постепенно отмирают...

A>Я так понимаю для тебя SQL и PHP языки одного типа. Печально.

Разберитесь для начала ЧТО такое SQL и что такое хранимые процедуры на T-SQL, а для развития почитайте еще про PL/SQL.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Потому что если есть возможность совершить ошибку, ты хоть миллион предупреждений повесь, всё равно найдётся дурак, который её совершит.
C>>В том числе и DBA в ХП, а эту ошибку потом будут долго отлаживать тупые прикладные пользователи, которые ни разу в жизни не написали ни одного запроса.
A>Извини, мы не об опечатках. Я ни разу не видел, чтобы разработчик БД сам написал SELECT с кривым планом для БД разработанной им же. Он значит притворяется разработчиком БД если так.
Планы для "SELECT ... WHERE a.name='aa'" он тоже проверяет? А ведь таких тривиальных запросов — больше всего.

A>>>Эти операции тебе понадобятся в любом случае. Никаких лишних сущностей тут нет.
C>>Есть. Я могу выкинуть кучу ручного труда с помощью разных автоматических байндеров и валидаторов.
A>Ты не можешь с помошью байндеров и валидаторов избежать неоптимизированного конечного SQL запроса. SQL запросы пишутся руками и я за то чтобы из писали только квалифицированны кадры, а не все подряд по мере надобности.
Т.е. разработчики будут стучать головой об стену, пока программисты БД не соизволят написать нужный запрос? Действительно, так и получается — сам видел.

А про оптимизацию сложных запросов я уже писал — это работа DBA, ее никто не отнимает.

C>>Если DBA знает только SQL — то он не сможет понять ТЗ, написаное аналитиком. Так что возможны два варианта:
A>Вполне сможет, если оно написано на уровне Entity-Relations.
Ага, кончено. А модель в виде готовой схемы БД от аналитика он так вообще хорошо может понять.

A>Это порочная практика. Рядовой разработчик никогда не сможет придумать действительно удачную схему хранения данных в БД. DBA должен плясать не от объектной модели, а от ER-диаграммы.
Для тебя будет сюрпризом, но ER-диаграммы прекрасно ложатся на объектную модель.

A>В описанном тобой сценарии DAL скорее всего выродится, так как БД будет отображать иерархию объектов, а не хранимые данные.
А иерархия объектов (кстати, использовали наследование в persistent-объектах всего несколько раз) — это не данные?

A>Подкрутить индексы и денормализовать чего-нибудь это далеко не самое главное в разработке схемы. Есть данные которые в реляционную модель, порой, просто не укладываются как есть и их надо преобразовывать до неузнаваемости.
Если они преобразуются до неузнаваемости — то программистам все равно придется с ними как-то работать. Так что опять никаких преимуществ.

C>>2. Аналитик дает задание DBA. DBA рисует схему и отдает ее программистам. Программисты по схеме строят DAL.
A>Хороший сценарий, мой любимый. Я получаю качественный продукт от человека, не сбитого с толку чьими-то неуместными ОО-идеями.
Ага, вот только обычно от DBA получаются далеко не самые удобные для использования схемы (типа с эмуляцией наследования с помощью CASE'ов).

C>>Случай когда тебе дают готовую схему БД означает, что приложение уже скорее всего было написано и работает. Тогда ничего не мешает тебе дать и готовый слой DAL (в виде отдельного модуля). Просто очень часто как раз делают псевдо-DAL на хранимках.
A>Нет, я всегда по мере возможности настаиваю чтобы БД разрабатывалась в первую очередь.
Мда...

C>>Хороший пример. А если у нас нет операции MoveArticle? Как ты в случае БД
A>Ты кажется не дописал вопрос. Во всяком случае он выглядит недописанным.
Да, странно. Сейчас надо вспомнить что я хотел написать

Надо меньше писать в 5 часов утра....

C>>На откуп DBA остаются только оптимизации сложных запросов и всякие сложные операции, требующие временных таблиц, километровых запросов и кувырков с переворотами. Вот тут, кстати, ХП как раз вполне подходят.
A>Это DBA-лентяи какие-то. Напрограммил то, что было самому интересно, а на остальное плюнул, путь негры пашут

Безответственно Почему именно — ниже (пометил знаком %).
Нет, это очень хороший подход — все делают то, что им нравится. А рутинная работа автоматизирована и ее вообще делает сам компьютер.

C>>Вот ты мне привел пример с XP для операций с User'ом. Не вижу там ни одного нетривиального SQL-оператора, который не смогу написать бы даже студент. Зачем тогда заставлять высококвалифицированного DBA заниматься этой ерундой?
A>Высококвалифицированного вероятно незачем, но даже такой ерундой кто-то должен заниматся не по мере надобности, а в соответствии с генеральным планом, потому что даже в такой ерунде можно наломать дров.
А почему бы не поручить эту работу самому компьютеру? Чем это хуже?

C>>А если мы даем программистам писать/править свои ХП — то тогда они уже у нас скорее всего не полные идиоты, неспособные понять даже простого SQL UPDATE.
A>% (пометка, которую ты ждал)
A>Проблема в том, что этот простой SQL UPDATE в деномализованной для чего-то там БД может разрушить целостность данных. DBA знает (помнит, записал, пометил для себя крестиком на пальце) что таблица денормализована и что обновив тут, надо ещё подкрутить там (кстати опять транзакция уровня БД, без неё никак). Рядовой программист этого не знает и может напортачить. А раз может, значит обязательно напортачит. Считай это законом Мерфи.
Кстати! Хорошее замечание, у нас была подобная проблема — неявная связь нескольких таблиц. В результате выловили несколько сложных ошибок, DBA забывали (по закону Мерфи!) синхронизировать таблицы (DBA ничего не заметил).

В результате написали набор декларативных правил, которые теперь следят за целостностью системы.

A>DBA не тормозит разработку как ты пытаешь представить, он не злой дядя-тормозун. Просто изменения большой системы с сохраненим её согласованности это конечно же куда более сложный и длительный процесс, чем написание "с нуля" как надо. Да, добавить столбец в таблицу оставив все запросы целостными может оказатся не просто. Но пусть этим занимается один человек, а иначе будут "сюрпризы".
Нет, нужно проектировать систему так, чтобы добавление столбцов ничего не ломало (или ломало как можно быстрее). А не надеятся на внимание одного человек.

Здравствуйте, adontz, Вы писали:

C>>Если DBA знает только SQL — то он не сможет понять ТЗ, написаное аналитиком. Так что возможны два варианта:

A>Вполне сможет, если оно написано на уровне Entity-Relations.

Где Вы видели такие ТЗ?

A>DBA должен плясать не от объектной модели, а от ER-диаграммы.

Да ну?

Кто Вам это сказал?

C>>Случай когда тебе дают готовую схему БД означает, что приложение уже скорее всего было написано и работает. Тогда ничего не мешает тебе дать и готовый слой DAL (в виде отдельного модуля). Просто очень часто как раз делают псевдо-DAL на хранимках.

A>Нет, я всегда по мере возможности настаиваю чтобы БД разрабатывалась в первую очередь.

Я бы хотел поинтересоваться, с чего Вы решили, что БД должна разрабатываться в первую очередь? Особенно, если речь о корпоративных приложениях?

C>>А если мы даем программистам писать/править свои ХП — то тогда они уже у нас скорее всего не полные идиоты, неспособные понять даже простого SQL UPDATE.

A>% (пометка, которую ты ждал)
A>Проблема в том, что этот простой SQL UPDATE в деномализованной для чего-то там БД может разрушить целостность данных. DBA знает (помнит, записал, пометил для себя крестиком на пальце) что таблица денормализована и что обновив тут, надо ещё подкрутить там (кстати опять транзакция уровня БД, без неё никак).

Мдаааааааааааа...................

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Cyberax, Вы писали:

C>Видимо, не использовал Hibernate в реальности

Кэш второго уровня там часто ускоряет работу в десятки раз, я об этом тут даже писал.

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

C>Нормальность (во всех смыслах) схемы ПРЕКРАСНО можно проверить вообще "на глаз". Если DBA не замечает таких явных косяков — то его увольнять надо. Расстановка неочевидных индексов, действительно, лучше всего делается по результатам нагрузочного тестирования (на тестовом сервере, не на production!).

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

C>Они сами так получаются. Причем, если программисты читают ХП, то у нас теряется один из мотивов их внедрения — разделения труда между разработчиками БД и приложения.

Программисты использующие ХП, читают, естесвенно, не весь код не ХП, а только описание (declaration).

C>Ты знаешь такой меееелкий тормозной проект как Google Adwords или Google Blogs? Так вот, их не существует, так как Hibernate в них используется.

Там есть HQL? HQL != Hibernate.

A>>Ну значит не всречался. Я вот встречался.
C>Чушь, чушь. Такие "падения производительности" были бы и с SQL, так как Hibernate не делает ничего магического.

Ну вот почему-то их нет.

C>http://hibernate.org/113.html
C>http://hibernate.org/290.html
C>(и это мааааааааааленькая часть общего количества)

C>Открой для себя mock objects

Я сейчас вообще слабо понимаю как без них тестировал раньше.

Тестирование знаешь вообще не панацея. Оно позволяет раньше вылавливать ошибки, но не позволяет лучше писать. Использование ORM приводит к выработке некоторых привычек, далеко не все из которых полезные.

C>Так если тормозит — втыкаем вместо HQL-запроса оптимизированый SQL. Какие проблемы-то? Hibernate позволяет замечательно использовать нативный SQL. Только вот нужно это всего в процентах случаев.

ХЗ, у нас этот процент оказался настолько большой, что HQL был отвергнут совсем. Может быть есть задачи на которых Hibernate генерирует что-то вменяемое, я больше сталкивался с другими задачами.

Здравствуйте, kuj, Вы писали:

kuj>Человек говорит Вам о рефакторинге и об опечатках в колонках. Когда у вас сотни процедур с таким вот именем колонки жестко прописанным в каждой процедуре...
kuj>В случае с OR/M, поменяв имя колонки в базе, мне достаточно поменять его всего-лишь раз в файле мэпинга, а Вам придется перелопачивать все сотни процедур да еще и без стредств рефакторинга.

Гуляй
http://www.google.com/search?q=sql+refactoring+tools

Здравствуйте, Aviator, Вы писали:

A>>Видишь ли, Hibernate как правило наботает в tier бизнесс-логики. У этого подхода есть преимущества в администрировании. Так что чего т так удивился я не особо понял.
A>Сам то понял что написал?

ОМГ. У тебя есть две машины, на одной всё что на java, на воторой SQL-сервер. Это достаточно стандартная схема.

A>Это sql, мы говорим о T-SQL и хранимках. типичный код хранимки не декларативный и представляет из себя жёское процедурное программирование

Это какая-то неправильная хранимка, она значит что-то лишнее делает.

A>Что понимается по как попало объясните пожалуйста, а то я начинаю терять нить изложения

.

Как попало обозначает "без виденья общей структуры БД, включая проведённые денормализации, кеширования и т.п.".
Нужно было работать с пользователями, прочитал документацию только про табличку Users, но не прочитал про таблички так или иначе с ней связанные и как следствие нарушил целостность данных некорерктными действиями.

Здравствуйте, Aviator, Вы писали:

kuj>>В случае с OR/M, поменяв имя колонки в базе, мне достаточно поменять его всего-лишь раз в файле мэпинга, а Вам придется перелопачивать все сотни процедур да еще и без стредств рефакторинга.
A>Подозреваю, что человек не знает что такое рефакторинг так что Ваш довод для него пустой звук

.

Слив защитан.

Здравствуйте, kuj, Вы писали:

kuj>Кстати говоря, SQL это ни разу не декларативный язык.

Сильно. Я это сообщение добавлю в favorites в раздел Юмор, можно?

Здравствуйте, kuj, Вы писали:

kuj>Наоборот тут речь о том, чтоб генерацией SQL-запросов занимался Hibernate (или т.п.), который прекрасно с этой задачей справляется, и в запросах, генерируемых Hibernate, Вы не увидете "*".

Это миф. В реальной системе соответствие поле_класса<->колонка_таблицы встречается достааточно редко! Hibernate просто не в состоянии автоматически построить подобные запросы.

Здравствуйте, kuj, Вы писали:

A>>Зависит от контекста. Иногда объекты ни к селу, ни к городу. В реляционной БД я места ООП не вижу.
kuj>Конечно не видете. Как же Вам видеть, если Вы вообще не понимаете о чем речь...

Давай я объясню просто, на примере. Если у тебя есть класс User вида

class User
{
   public Guid ID {get;set};
   public string Login {get;set}
   public string FirstName {get;set}
   public string LastName {get;set}
   public ChangePassword(string oldPassword, string newPassword)
   ...
}

То ты, как адепт ОРМ, конечно же создашь таблицу с полями ID, Login, Password, FirstName, LastName. В нормальной, расширяемой БД такого не будет. Будет таблица Users (ID, Login, Password) и таблица UserProperties (UserID REFERENCES (Users.ID), PropertyName, PropertyValue). Это верное решение, потому что добавление полей в клас User никак не забрачивает схему БД, DAL и т.п. Чтобы такие правильные решения принимать надо при построении БД плясать не от иерархии объектов, а от представляемых сущностей. Фактически ORM это зло, действительно правильно делать ROM, так как только в этом случае можно получить вменяемую БД, построенную как надо и не являющуюся жалкой тенью чужеродного ей понятия иерархии объектов. ООП в БД делать нечего, Entity-Relations описанные в ТЗ ложатся в БД один к одному, объекты — нет. объекты вторичны, ER — первичны и именно на их основе надо строить БД.

Здравствуйте, Cyberax, Вы писали:

A>>Извини, мы не об опечатках. Я ни разу не видел, чтобы разработчик БД сам написал SELECT с кривым планом для БД разработанной им же. Он значит притворяется разработчиком БД если так.
C>Планы для "SELECT ... WHERE a.name='aa'" он тоже проверяет? А ведь таких тривиальных запросов — больше всего.

Нет, он пишет ХП план которой разбирает один раз. Остальные пользуются ХП с проверенным планом. вот для того и нужны ХП, что это гарантированный способ не напортачить.

C>Т.е. разработчики будут стучать головой об стену, пока программисты БД не соизволят написать нужный запрос? Действительно, так и получается — сам видел.

Значит БД плохо расширяемая если на каждый чихз надо новый запрос писать. Пример про таблицы Users и Users-UserProperties я уже привёл.

A>>Вполне сможет, если оно написано на уровне Entity-Relations.
C>Ага, кончено. А модель в виде готовой схемы БД от аналитика он так вообще хорошо может понять.

Я всегда требую описания ER, иначе это не ТЗ, а филькина грамота.

C>Для тебя будет сюрпризом, но ER-диаграммы прекрасно ложатся на объектную модель.

Далеко не всегда. У БД с этим намного лучше.

C>А иерархия объектов (кстати, использовали наследование в persistent-объектах всего несколько раз) — это не данные?

В общем случае иерархия объектов это НЕ данные. Ты разве не знал?

C>Если они преобразуются до неузнаваемости — то программистам все равно придется с ними как-то работать. Так что опять никаких преимуществ.

проблема в том, что их вовремя не пробразовывают строя БД как зеркало иерархии объектов, а не для хранения даных.

C>Ага, вот только обычно от DBA получаются далеко не самые удобные для использования схемы (типа с эмуляцией наследования с помощью CASE'ов).

Это уже мои проблемы, его дело эффективность. Можно найти компромисс, но БД первична и не должна строится на основе иерархии объектов.

C>А почему бы не поручить эту работу самому компьютеру? Чем это хуже?

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

A>>Проблема в том, что этот простой SQL UPDATE в деномализованной для чего-то там БД может разрушить целостность данных. DBA знает (помнит, записал, пометил для себя крестиком на пальце) что таблица денормализована и что обновив тут, надо ещё подкрутить там (кстати опять транзакция уровня БД, без неё никак). Рядовой программист этого не знает и может напортачить. А раз может, значит обязательно напортачит. Считай это законом Мерфи.

C>Кстати! Хорошее замечание, у нас была подобная проблема — неявная связь нескольких таблиц. В результате выловили несколько сложных ошибок, DBA забывали (по закону Мерфи!) синхронизировать таблицы (DBA ничего не заметил).
C>В результате написали набор декларативных правил, которые теперь следят за целостностью системы.

Хммм... может у вас DBA нормальных нет? Вот и обходитесь другими стредствами? Я-то с монстрами работал, повезло конечно, вот и привык доверять. ХЗ, конечно всегда надо исходить из квалификации тех с кем работаешь, но у меня таких проблем точно не было.

A>>DBA не тормозит разработку как ты пытаешь представить, он не злой дядя-тормозун. Просто изменения большой системы с сохраненим её согласованности это конечно же куда более сложный и длительный процесс, чем написание "с нуля" как надо. Да, добавить столбец в таблицу оставив все запросы целостными может оказатся не просто. Но пусть этим занимается один человек, а иначе будут "сюрпризы".

C>Нет, нужно проектировать систему так, чтобы добавление столбцов ничего не ломало (или ломало как можно быстрее). А не надеятся на внимание одного человек.

Нет, надо проектировать систему так, чтобы расширения функиональности не сопровождалось добавлением новых столбцов

Здравствуйте, kuj, Вы писали:

kuj>Где Вы видели такие ТЗ?

В руках держал.

A>>DBA должен плясать не от объектной модели, а от ER-диаграммы.
kuj>Да ну?

Кто Вам это сказал?

Так лучше выходит.

A>>Нет, я всегда по мере возможности настаиваю чтобы БД разрабатывалась в первую очередь.
kuj>Я бы хотел поинтересоваться, с чего Вы решили, что БД должна разрабатываться в первую очередь?

Скажем так, тут не столько важна хронология, сколько важно отсутствие влияния объектной модели на разработку БД.

Здравствуйте, AndrewJD, Вы писали:

kuj>>ХП vs запросы? О чем Вы?
AJD>Хм. А о чем ветка? Разве не о преимуществах/недостатках использования ХП?

Нет, ветка у нас получалась Object-Relational Mappers против Хранимых Процедур.
Скоро kuj поднимет ветку C# против Алгоритмов.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kuj, Вы писали:

kuj>>Наоборот тут речь о том, чтоб генерацией SQL-запросов занимался Hibernate (или т.п.), который прекрасно с этой задачей справляется, и в запросах, генерируемых Hibernate, Вы не увидете "*".

A>Это миф. В реальной системе соответствие поле_класса<->колонка_таблицы встречается достааточно редко! Hibernate просто не в состоянии автоматически построить подобные запросы.
Да что вы говорите

. Вы статистику по проектам собирали или говорите на основании вашего горького опыта?

Уже даже не смешно...

Здравствуйте, adontz, Вы писали:

C>>Видимо, не использовал Hibernate в реальности

Кэш второго уровня там часто ускоряет работу в десятки раз, я об этом тут даже писал.
A>Любой кеш, как только у тебя появляется несколько серверов, надо между ними синхронизировать. Либо сбрасывать (плохо), либо подправлять (сложно). В любом случае, трафик синхронизации кеша между элементами кластера — зло, так как рождает топологию все-ко-всем, абсолютно не масштабируемую по определению.
Видимо, ты никогда не видел: http://tangosol.com/coherence-overview.jsp — кластерный транзакционный кэш, легко масштабируется на десятки машин (но стоит денег, сволочь). Сейчас используем тупой JBoss Cache — на кластере из пяти машин все спокойно живет, даже 100MBit не заполняет.

Кстати, получается намного эффективнее, чем без кэша — куча простых запросов до БД даже не доходит.

C>>Нормальность (во всех смыслах) схемы ПРЕКРАСНО можно проверить вообще "на глаз". Если DBA не замечает таких явных косяков — то его увольнять надо. Расстановка неочевидных индексов, действительно, лучше всего делается по результатам нагрузочного тестирования (на тестовом сервере, не на production!).
A>Дело в том, что то как ты хранишь данные во многом зависит от того, что ыт потом с ними собираешься делать и добавление новой операции может привести к пересмотру способа хранения.
Замечательно. Поменяли способ хранения. Что дальше? Вариантов всего два:
1) Ляпать заплатки в виде видов для совместимости, хранимых процедур и т.п. Именно так обычно и поступают DBA.
2) Зарефакторить приложение. Тут несомненным лидером являются нормальные языки.

C>>Они сами так получаются. Причем, если программисты читают ХП, то у нас теряется один из мотивов их внедрения — разделения труда между разработчиками БД и приложения.
A>Программисты использующие ХП, читают, естесвенно, не весь код не ХП, а только описание (declaration).
Ага, а в коде ХП ошибок ну вообще никогда не бывает, конечно?

C>>Ты знаешь такой меееелкий тормозной проект как Google Adwords или Google Blogs? Так вот, их не существует, так как Hibernate в них используется.
A>Там есть HQL? HQL != Hibernate.
Есть

Создатели Google Blogs написали неплохой guide про использование Hibernate в таких приложениях. Про HQL там тоже глава была.

Собственно, HQL — это просто другая запись SQL. Так что ничего удивительного, да еще и в следующей версии собираются добавить прямо в HQL поддержку DB-specific хинтов.

C>>Открой для себя mock objects

Я сейчас вообще слабо понимаю как без них тестировал раньше.
A>Тестирование знаешь вообще не панацея. Оно позволяет раньше вылавливать ошибки, но не позволяет лучше писать. Использование ORM приводит к выработке некоторых привычек, далеко не все из которых полезные.
Ага, такие вредные привычки как легкорефакторируемый код и запросы. Например, вот так умеет новая IDEA:

Я специально сделал ошибки: неправильное имя поля и установку несуществующего параметра. Обрати внимание на подсветку синтаксиса запроса. Естественно, при редактировании запроса работает автокомплит, рефакторинг и т.п.

А если у меня в mapping'е будет ошибка, то получится примерно так:

Т.е. IDE автоматически сравнивает mapping с реальной схемой и находит ошибки.

C>>Так если тормозит — втыкаем вместо HQL-запроса оптимизированый SQL. Какие проблемы-то? Hibernate позволяет замечательно использовать нативный SQL. Только вот нужно это всего в процентах случаев.
A>ХЗ, у нас этот процент оказался настолько большой, что HQL был отвергнут совсем. Может быть есть задачи на которых Hibernate генерирует что-то вменяемое, я больше сталкивался с другими задачами.
Hibernate генерирует абсолютно очевидный SQL. Что там такое у вас было??

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kuj, Вы писали:

kuj>>Кстати говоря, SQL это ни разу не декларативный язык.

A>Сильно. Я это сообщение добавлю в favorites в раздел Юмор, можно?
Для начала почитайте в гугле что такое T-SQL. А то создаётся ощущение, что Вы защищаете то, о чём у Вас практически нет представления

Здравствуйте, adontz, Вы писали:

A>>>Видишь ли, Hibernate как правило наботает в tier бизнесс-логики. У этого подхода есть преимущества в администрировании. Так что чего т так удивился я не особо понял.
A>>Сам то понял что написал?
A>ОМГ. У тебя есть две машины, на одной всё что на java, на воторой SQL-сервер. Это достаточно стандартная схема.
У меня вот два сервера БД (кластер с failover) и 3 app-сервера в качестве front-end'ов. Все прекрасно работает с Hibernate.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, AndrewJD, Вы писали:

kuj>>>ХП vs запросы? О чем Вы?
AJD>>Хм. А о чем ветка? Разве не о преимуществах/недостатках использования ХП?

A>Нет, ветка у нас получалась Object-Relational Mappers против Хранимых Процедур.
A>Скоро kuj поднимет ветку C# против Алгоритмов.
Видите ли, Ваша позиция напоминает программистов, которые в стародавние временна утверждали, что реальтный пацаны пишут на асме, где полный контроль машины, С для недоделанных. Дальше были дискуссии, что у Java/.NET нет будущего, на них приложения всегда будут проигрывать в эффективности С++... Время расставило всё на свои места.

Здравствуйте, adontz, Вы писали:

A>То ты, как адепт ОРМ, конечно же создашь таблицу с полями ID, Login, Password, FirstName, LastName. В нормальной, расширяемой БД такого не будет. Будет таблица Users (ID, Login, Password) и таблица UserProperties (UserID REFERENCES (Users.ID), PropertyName, PropertyValue). Это верное решение, потому что добавление полей в клас User никак не забрачивает схему БД, DAL и т.п.
Ты знаешь, если мне это нужно будет — я точно так же сделаю два класса User и UserDetails. А если у нас только два поля FirstName/LastName — пусть себе живут в одной таблице.

A>Чтобы такие правильные решения принимать надо при построении БД плясать не от иерархии объектов, а от представляемых сущностей. Фактически ORM это зло, действительно правильно делать ROM, так как только в этом случае можно получить вменяемую БД, построенную как надо и не являющуюся жалкой тенью чужеродного ей понятия иерархии объектов. ООП в БД делать нечего, Entity-Relations описанные в ТЗ ложатся в БД один к одному, объекты — нет. объекты вторичны, ER — первичны и именно на их основе надо строить БД.
ER-диаграммы ОДИН-В-ОДИН (т.е. автоматически) могут переводится на объектную модель.

adontz
Не надоело минусы ставить?

Не ну серьёзно, удивляет упорство, теперь я понимаю почему ты так защищаешь хранимки

Здравствуйте, adontz, Вы писали:

kuj>>>ХП vs запросы? О чем Вы?
AJD>>Хм. А о чем ветка? Разве не о преимуществах/недостатках использования ХП?
A>Нет, ветка у нас получалась Object-Relational Mappers против Хранимых Процедур.
Нет. Спор о том, что из ХП часто делают poor-man's DAL, что более нормально делается более нормальными инструментами.

Здравствуйте, Aviator, Вы писали:

A>Да что вы говорите

. Вы статистику по проектам собирали или говорите на основании вашего горького опыта?

Уже даже не смешно...

Просто не только складским учётом занимаюсь.

Здравствуйте, adontz, Вы писали:

C>>Планы для "SELECT ... WHERE a.name='aa'" он тоже проверяет? А ведь таких тривиальных запросов — больше всего.
A>Нет, он пишет ХП план которой разбирает один раз. Остальные пользуются ХП с проверенным планом. вот для того и нужны ХП, что это гарантированный способ не напортачить.
Ну вот пусть спокойно пишет его и вставляет как именованый запрос в hbm.xml-файл (файл мэппинга). Только вот нужно это крайне редко.

C>>Т.е. разработчики будут стучать головой об стену, пока программисты БД не соизволят написать нужный запрос? Действительно, так и получается — сам видел.
A>Значит БД плохо расширяемая если на каждый чихз надо новый запрос писать. Пример про таблицы Users и Users-UserProperties я уже привёл.
БД расширяется прекрасно. Но у тебя запросы же отдельные люди пишут — а нужно это постоянно.

Про пример User/UserDetails — могу для тебя скринкаст сделать как я могу сделать рефакторинг из одного класса User.

A>>>Вполне сможет, если оно написано на уровне Entity-Relations.
C>>Ага, кончено. А модель в виде готовой схемы БД от аналитика он так вообще хорошо может понять.
A>Я всегда требую описания ER, иначе это не ТЗ, а филькина грамота.
Везет некоторым...

C>>Для тебя будет сюрпризом, но ER-диаграммы прекрасно ложатся на объектную модель.
A>Далеко не всегда. У БД с этим намного лучше.
Везде. Классические ER-диаграммы автоматически на объекты отображаются (собственно, куча MDA-тулзов только и занимаются этим).

C>>А иерархия объектов (кстати, использовали наследование в persistent-объектах всего несколько раз) — это не данные?

A>В общем случае иерархия объектов это НЕ данные. Ты разве не знал?
Если не учитывать поведение объектов — всегда данные. Но не всегда красиво ложатся на реляционную модель.

C>>Если они преобразуются до неузнаваемости — то программистам все равно придется с ними как-то работать. Так что опять никаких преимуществ.
A>проблема в том, что их вовремя не пробразовывают строя БД как зеркало иерархии объектов, а не для хранения даных.
Что значит "не вовремя"?

C>>Ага, вот только обычно от DBA получаются далеко не самые удобные для использования схемы (типа с эмуляцией наследования с помощью CASE'ов).
A>Это уже мои проблемы, его дело эффективность. Можно найти компромисс, но БД первична и не должна строится на основе иерархии объектов.
Прекрасно — вот тебе колоночная DB на K. Писать программы тоже только на K. Будешь?

A>Хммм... может у вас DBA нормальных нет? Вот и обходитесь другими стредствами? Я-то с монстрами работал, повезло конечно, вот и привык доверять. ХЗ, конечно всегда надо исходить из квалификации тех с кем работаешь, но у меня таких проблем точно не было.
Вроде нормальный — запросы оптимизирует очень круто.

C>>Нет, нужно проектировать систему так, чтобы добавление столбцов ничего не ломало (или ломало как можно быстрее). А не надеятся на внимание одного человек.
A>Нет, надо проектировать систему так, чтобы расширения функиональности не сопровождалось добавлением новых столбцов

Это обычно нереально

Здравствуйте, Cyberax, Вы писали:

C>Видимо, ты никогда не видел: http://tangosol.com/coherence-overview.jsp — кластерный транзакционный кэш, легко масштабируется на десятки машин (но стоит денег, сволочь). Сейчас используем тупой JBoss Cache — на кластере из пяти машин все спокойно живет, даже 100MBit не заполняет.

Этого действительно не видел. Суть проблемы это не меняет, неактуальный кеш — зло, эффективное поддержание кеша в актуальном состоянии — нетривиальная задача. Кстати ненасыщенность 100Мбит это не показатель. Сравнивать надо это с физическим ограничением сети, а с трафиком к клиентам.

C>Кстати, получается намного эффективнее, чем без кэша — куча простых запросов до БД даже не доходит.

Кеш вообще штука хорошая, просто опасная.

A>>Программисты использующие ХП, читают, естесвенно, не весь код не ХП, а только описание (declaration).
C>Ага, а в коде ХП ошибок ну вообще никогда не бывает, конечно?

Меньше, чем в запросах написанных не DBA.

C>Ага, такие вредные привычки как легкорефакторируемый код и запросы. Например, вот так умеет новая IDEA:
C>

Нет, абсолютное забыванеи об индексах и представление, что объекты это точка отсчёта.

C>Hibernate генерирует абсолютно очевидный SQL. Что там такое у вас было??

Неочевидный SQL

Я же говорю, БД и объекты очень сильно различались.

Здравствуйте, Cyberax, Вы писали:

A>>ОМГ. У тебя есть две машины, на одной всё что на java, на воторой SQL-сервер. Это достаточно стандартная схема.
C>У меня вот два сервера БД (кластер с failover) и 3 app-сервера в качестве front-end'ов. Все прекрасно работает с Hibernate.

Почетай выше о чём вообще речь, kuj совсем не понимает чем транзакции уровня БД отличаются от транзакций уровня бизнес-логики.

Здравствуйте, Aviator, Вы писали:

A>Видите ли, Ваша позиция напоминает программистов, которые в стародавние временна утверждали, что реальтный пацаны пишут на асме, где полный контроль машины, С для недоделанных. Дальше были дискуссии, что у Java/.NET нет будущего, на них приложения всегда будут проигрывать в эффективности С++... Время расставило всё на свои места.

Видишь ли, у меня много-много лет опыта работы за спиной и я знаю что панацеи нет и любая технология, самая хорошая вообще, обязательно облажается на какой-нибудь конкретной задаче. Hibernate это очень удобно и хорошо (кто бы спорил), но не всегда применимо. Без ХП писать можно, более того мелкие проекты нужно писать без ХП. В большинстве приложений не нужен MVC, достаточно Document-View. Вообще из пушки по воробьям стрелять не надо. Я реально сталкивался с задачами где реляционная модель и объекная раличались очень сильно и использоание ORM превращаось в мучение, в результате отказывались. Есть задачи не тестируемые автоматически в принципе, так что никакой TDD не спасёт. Вообще не надо верить в технологии, у них всегда есть область применения, зачастую довольно узкая.

Здравствуйте, Cyberax, Вы писали:

C>Ты знаешь, если мне это нужно будет — я точно так же сделаю два класса User и UserDetails. А если у нас только два поля FirstName/LastName — пусть себе живут в одной таблице.

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

C>ER-диаграммы ОДИН-В-ОДИН (т.е. автоматически) могут переводится на объектную модель.

Ну и как? Приличная модель выходит?

Руками всё равно надо править...

Здравствуйте, Aviator, Вы писали:

A> Не надоело минусы ставить?

Минус выражает несогласие. В чём проблема? Если тебя это задевает лично, я могу убрать. Оценка вообще-то ставится сообщению, а не автору.

A>Не ну серьёзно, удивляет упорство, теперь я понимаю почему ты так защищаешь хранимки

ХП мне просто нравятся. Было долгое время, когда я писал без них. Я жестоко ошибался.

Здравствуйте, Cyberax, Вы писали:

C>Нет. Спор о том, что из ХП часто делают poor-man's DAL, что более нормально делается более нормальными инструментами.

А я к этому не призывал. Охотиться на ведьм можете в другом месте

Здравствуйте, Cyberax, Вы писали:

C>>>А иерархия объектов (кстати, использовали наследование в persistent-объектах всего несколько раз) — это не данные?

A>>В общем случае иерархия объектов это НЕ данные. Ты разве не знал?
C>Если не учитывать поведение объектов — всегда данные. Но не всегда красиво ложатся на реляционную модель.

Скажем так, объекты не всегда entities. В реляционную модельне укладываются очень часто. Увы.

C>>>Если они преобразуются до неузнаваемости — то программистам все равно придется с ними как-то работать. Так что опять никаких преимуществ.
A>>проблема в том, что их вовремя не пробразовывают строя БД как зеркало иерархии объектов, а не для хранения даных.
C>Что значит "не вовремя"?

Не вовремя значит, что сперва сделали БД отражение иерархии объектов (по табличке на тип, по столбцу на поле) и решили что это хорошо. а потом вдруг выяснилось что так хранить данные крайне не эффективно. И начали не вовремя их менять. Вовремя, это если бы продумали БД с самого начала. То есть исходя из данных и операций, а не иерархии объектов.

C>Прекрасно — вот тебе колоночная DB на K. Писать программы тоже только на K. Будешь?

Что такое К?

A>>Нет, надо проектировать систему так, чтобы расширения функиональности не сопровождалось добавлением новых столбцов

C>Это обычно нереально

Ну не каждый же чих...

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Cyberax, Вы писали:
C>>Нет. Спор о том, что из ХП часто делают poor-man's DAL, что более нормально делается более нормальными инструментами.
A>А я к этому не призывал. Охотиться на ведьм можете в другом месте

Тем не менее, твои примеры ХП — это как раз пример DAL.

Здравствуйте, adontz, Вы писали:

C>>Видимо, ты никогда не видел: http://tangosol.com/coherence-overview.jsp — кластерный транзакционный кэш, легко масштабируется на десятки машин (но стоит денег, сволочь). Сейчас используем тупой JBoss Cache — на кластере из пяти машин все спокойно живет, даже 100MBit не заполняет.
A>Этого действительно не видел. Суть проблемы это не меняет, неактуальный кеш — зло, эффективное поддержание кеша в актуальном состоянии — нетривиальная задача.
Для меня — тривиальная. Просто расставить '<cache usage="transactional"/>' в мэппинге. Остальное оно все само сделает (и делает!). Естественно, доступ к БД должен вестись только через Hibernate. Хотя в NHibernate есть инвалидация кэша по оповещениям от MSSQL — так что даже это ограничение снимается.

A>Кстати ненасыщенность 100Мбит это не показатель. Сравнивать надо это с физическим ограничением сети, а с трафиком к клиентам.
Клиенты ломятся через канал в 70Мбит с exchange'а на котором хостимся. Заполняют полностью в ЧНН.

A>>>Программисты использующие ХП, читают, естесвенно, не весь код не ХП, а только описание (declaration).
C>>Ага, а в коде ХП ошибок ну вообще никогда не бывает, конечно?
A>Меньше, чем в запросах написанных не DBA.
Не знаю, вряд ли.

C>>Ага, такие вредные привычки как легкорефакторируемый код и запросы. Например, вот так умеет новая IDEA:
C>>

A>Нет, абсолютное забыванеи об индексах и представление, что объекты это точка отсчёта.
А причем тут индексы? Они в mapping'е вообще не указываются, так как это деталь реализации, ей занимается DBA, которому нафиг не надо лазить в файлы mapping'а (разделение труда!).

C>>Hibernate генерирует абсолютно очевидный SQL. Что там такое у вас было??
A>Неочевидный SQL

Я же говорю, БД и объекты очень сильно различались.
Может все-таки тогда стоило объектную модель подправить?

Здравствуйте, adontz, Вы писали:

C>>Ты знаешь, если мне это нужно будет — я точно так же сделаю два класса User и UserDetails. А если у нас только два поля FirstName/LastName — пусть себе живут в одной таблице.
A>Это надо делать не когда нужно, а на всякий случай. Именно это и отличает хорошего специальста, что он разрабатывает продукт не только для сегодняшнего дня, а с учётом возможных расширений.
Сразу ВСЕХ? А почему тогда явно указан password? А где секретный вопрос? А возможность использовать Kerberos куда дели? А почему не поддерживается OpenID?!!?!

C>>ER-диаграммы ОДИН-В-ОДИН (т.е. автоматически) могут переводится на объектную модель.
A>Ну и как? Приличная модель выходит?

Руками всё равно надо править...
Обычно правки заключаются в добавлении явного наследования (там где это надо), приукрашению денормализованого представления и прочих мелочей.

Здравствуйте, adontz, Вы писали:

A>>>Извини, мы не об опечатках. Я ни разу не видел, чтобы разработчик БД сам написал SELECT с кривым планом для БД разработанной им же. Он значит притворяется разработчиком БД если так.
C>>Планы для "SELECT ... WHERE a.name='aa'" он тоже проверяет? А ведь таких тривиальных запросов — больше всего.
A>Нет, он пишет ХП план которой разбирает один раз. Остальные пользуются ХП с проверенным планом.
Простите что пишет? План?

A>вот для того и нужны ХП, что это гарантированный способ не напортачить.
ХП это гарантированный способ не напортачить? Кто Вам эту чушь сказал?

C>>Т.е. разработчики будут стучать головой об стену, пока программисты БД не соизволят написать нужный запрос? Действительно, так и получается — сам видел.
A>Значит БД плохо расширяемая если на каждый чихз надо новый запрос писать.
Для того и нужны OR/M — чтоб не писать на каждый чих запрос.
A>Пример про таблицы Users и Users-UserProperties я уже привёл.
Вот, как это просто в случае с AR выглядит (таблицы Users — UserProperties — Properties):

Property p = new ...
p.Prop1 = ...;
p.Prop2 = ...;
...
p.Save();

User user = new ...
user.Properties.Add(p);
...

user.SaveAndFlush();

Будет автоматически сгенерирован пакет запросов SQL в виде INSERT`ов: первый в таблицу, на которую замаплен Property, второй в таблицу для User, третий в таблицу связи UserProperties.

теперь если что-то меняем. например, user.SomeProp = ...; user.SaveAndFlush(); то в этот раз будет сгенерирован UPDATE на конкретно поле (поля), на которое замаплено SomeProp.

Вся CRUD-логика автоматически в нашем полном распоряжении.

Единственное, что вызывает некоторые сложности это таблицы с иерархической структурой данных (типа дерева или списочной структуры). Но и такие ситуации разруливаются без особых проблем и они, к слову, довольно редки. По-крайней мере на моем опыте.

A>>>Вполне сможет, если оно написано на уровне Entity-Relations.
C>>Ага, кончено. А модель в виде готовой схемы БД от аналитика он так вообще хорошо может понять.

A>Я всегда требую описания ER, иначе это не ТЗ, а филькина грамота.

Зачем Вам ER-схемы, если Вы не занимаетесь DAL?

C>>Для тебя будет сюрпризом, но ER-диаграммы прекрасно ложатся на объектную модель.

A>Далеко не всегда. У БД с этим намного лучше.

Смешно.

C>>А иерархия объектов (кстати, использовали наследование в persistent-объектах всего несколько раз) — это не данные?

A>В общем случае иерархия объектов это НЕ данные. Ты разве не знал?

Объект, а точнее класс — это совокупность данных и методов.

C>>Если они преобразуются до неузнаваемости — то программистам все равно придется с ними как-то работать. Так что опять никаких преимуществ.

A>проблема в том, что их вовремя не пробразовывают строя БД как зеркало иерархии объектов, а не для хранения даных.

И это по-вашему мешает БД хранить данные?

C>>Ага, вот только обычно от DBA получаются далеко не самые удобные для использования схемы (типа с эмуляцией наследования с помощью CASE'ов).

A>Это уже мои проблемы, его дело эффективность. Можно найти компромисс, но БД первична и не должна строится на основе иерархии объектов.

Ну-ну... Как же Вы отстали от жизни...

C>>Кстати! Хорошее замечание, у нас была подобная проблема — неявная связь нескольких таблиц. В результате выловили несколько сложных ошибок, DBA забывали (по закону Мерфи!) синхронизировать таблицы (DBA ничего не заметил).
C>>В результате написали набор декларативных правил, которые теперь следят за целостностью системы.

A>Хммм... может у вас DBA нормальных нет? Вот и обходитесь другими стредствами? Я-то с монстрами работал, повезло конечно, вот и привык доверять. ХЗ, конечно всегда надо исходить из квалификации тех с кем работаешь, но у меня таких проблем точно не было.

Кадры приходят и уходят, а проекты остаются. Если Вы на столько полагаетесь на одного-двух разработчиков БД, то Ваши прожект-менеджеры, простите, полные идиоты. Как только они уволятся Вы все останетесь у разбитого корыта в виде громадного количества T-SQL кода со сложными зависимостями и почти полным отсутствием документации. Отствие же модульных тестов сделает рефакторинг задачей абсолютно из ряда фантастики... Вообщем удачи с таким допотопным подходом.

A>>>DBA не тормозит разработку как ты пытаешь представить, он не злой дядя-тормозун. Просто изменения большой системы с сохраненим её согласованности это конечно же куда более сложный и длительный процесс, чем написание "с нуля" как надо. Да, добавить столбец в таблицу оставив все запросы целостными может оказатся не просто. Но пусть этим занимается один человек, а иначе будут "сюрпризы".

C>>Нет, нужно проектировать систему так, чтобы добавление столбцов ничего не ломало (или ломало как можно быстрее). А не надеятся на внимание одного человек.

A>Нет, надо проектировать систему так, чтобы расширения функиональности не сопровождалось добавлением новых столбцов

Это фантастика. Требования постоянно меняются. Постоянно. Потому и выдумают различные agile-методы, tdd, ddd и прочие новомодные приемы и техники.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>DBA должен плясать не от объектной модели, а от ER-диаграммы.
kuj>>Да ну?

Кто Вам это сказал?

A>Так лучше выходит.

А я Вам скажу, что так выходит хуже. При чем гораздо хуже.

A>>>Нет, я всегда по мере возможности настаиваю чтобы БД разрабатывалась в первую очередь.
kuj>>Я бы хотел поинтересоваться, с чего Вы решили, что БД должна разрабатываться в первую очередь?

A>Скажем так, тут не столько важна хронология, сколько важно отсутствие влияния объектной модели на разработку БД.

Мда... я не завидую вашим разработчикам БД, но еще больше я не завидую вашим разработчикам BLL...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

C>>>>А иерархия объектов (кстати, использовали наследование в persistent-объектах всего несколько раз) — это не данные?

A>>>В общем случае иерархия объектов это НЕ данные. Ты разве не знал?
C>>Если не учитывать поведение объектов — всегда данные. Но не всегда красиво ложатся на реляционную модель.

A>Скажем так, объекты не всегда entities. В реляционную модельне укладываются очень часто. Увы.

Конечно... Если как Вы предлагаете — сначала делать схему БД, а потом пытаться на нее натянуть...

C>>>>Если они преобразуются до неузнаваемости — то программистам все равно придется с ними как-то работать. Так что опять никаких преимуществ.
A>>>проблема в том, что их вовремя не пробразовывают строя БД как зеркало иерархии объектов, а не для хранения даных.
C>>Что значит "не вовремя"?

A>Не вовремя значит, что сперва сделали БД отражение иерархии объектов (по табличке на тип, по столбцу на поле) и решили что это хорошо. а потом вдруг выяснилось что так хранить данные крайне не эффективно.

А как их эффективно хранить? Просвятите нас неведающих...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>Наоборот тут речь о том, чтоб генерацией SQL-запросов занимался Hibernate (или т.п.), который прекрасно с этой задачей справляется, и в запросах, генерируемых Hibernate, Вы не увидете "*".

A>Это миф. В реальной системе соответствие поле_класса<->колонка_таблицы встречается достааточно редко! Hibernate просто не в состоянии автоматически построить подобные запросы.

Кто вам эту чушь сказал?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Зависит от контекста. Иногда объекты ни к селу, ни к городу. В реляционной БД я места ООП не вижу.
kuj>>Конечно не видете. Как же Вам видеть, если Вы вообще не понимаете о чем речь...

A>Давай я объясню просто, на примере. Если у тебя есть класс User вида
A>

A>class User
A>{
A>   public Guid ID {get;set};
A>   public string Login {get;set}
A>   public string FirstName {get;set}
A>   public string LastName {get;set}
A>   public ChangePassword(string oldPassword, string newPassword)
A>   ...
A>}
A>

A>То ты, как адепт ОРМ, конечно же создашь таблицу с полями ID, Login, Password, FirstName, LastName. В нормальной, расширяемой БД такого не будет. Будет таблица Users (ID, Login, Password) и таблица UserProperties (UserID REFERENCES (Users.ID), PropertyName, PropertyValue).
Интересно, а что мне помешает сделать то же самое в ORM? Думаете, я не смогу one-to-one relation в файле мэппинга прописать?

Вот еще один пример того, что делается элементарно в ORM. Т.н. nested type hieratchies — http://www.castleproject.org/activerecord/documentation/trunk/usersguide/typehierarchy.html

Хотел бы я посмотреть как Вы это запрограмируете на ХП.

A>Это верное решение, потому что добавление полей в клас User никак не забрачивает схему БД, DAL и т.п. Чтобы такие правильные решения принимать надо при построении БД плясать не от иерархии объектов, а от представляемых сущностей. Фактически ORM это зло, действительно правильно делать ROM, так как только в этом случае можно получить вменяемую БД, построенную как надо и не являющуюся жалкой тенью чужеродного ей понятия иерархии объектов. ООП в БД делать нечего, Entity-Relations описанные в ТЗ ложатся в БД один к одному, объекты — нет. объекты вторичны, ER — первичны и именно на их основе надо строить БД.

Зло это то, что Вы продолжаете спорить, ни капли не разбираясь в вопросе и даже не пытаясь разобраться.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>Человек говорит Вам о рефакторинге и об опечатках в колонках. Когда у вас сотни процедур с таким вот именем колонки жестко прописанным в каждой процедуре...
kuj>>В случае с OR/M, поменяв имя колонки в базе, мне достаточно поменять его всего-лишь раз в файле мэпинга, а Вам придется перелопачивать все сотни процедур да еще и без стредств рефакторинга.

A>Гуляй
A>http://www.google.com/search?q=sql+refactoring+tools

Рефакторинг без юнит тестов? Удачи.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Добрый вечер,

Я автор темы

Очень интересно читать Вашу беседу.
ОЧЕНЬ хотелось бы попросить, чтобы вы привели примеры кода, с разных уровней, т.е. как выглядит код в уровне GUI (в обработчиках кнопок например), этот код будет взаимодействовать с объектами из следующего уровня — приведите код из следующего уровня и т.д. Т.е. чтобы можно было кратко представить целую картину по оформлению работы с БД в приложении. А то сейчас все довольно абстрагировано, по крайней мере для меня — человека НЕ С ВАШИМ уровнем и опытом.
Это относится к обоим выделившимся сторонам обсуждения (Adontz и все остальные

.

Дальше есть несколько вопросов:

1) Как реализации ORM будут работать с MySQL? Например в последнем приложении я использую MySQL. Т.е. вообще для какой СУБД генерируются запросы? Простите если чего-то не понимаю.

2) Что если у запроса есть много параметров, появление которых зависит от различных checkbox'ов или radiobox'ов на форме. Нет ли проблем в таких случаях? Я так понимаю что нет, т.к. в случае ORM запрос будет генерироваться на основе только выбранных параметров, а в случае с ХП используется dynamic sql?

3) Как проявляют себя 2 выделенные технологии на небольших-средних проектах (БД из 30 — 50 таблиц, есть маленькие таблицы, есть таблицы с миллионами записей)? Или на какого размера проекты ориентированы обсуждаемые подходы?

4) Можно ли подробный пример действий, которые вы производите при модификации БД, например при добавлении/удалении столбца, или выноса нескольких столбцов в отдельную таблицу и замену их ключом (NewTableID) в оригинальной таблице?

5) Я так понимаю что BLT, LINQ это все реализации ORM ?

Заранее большое спасибо.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>>Видишь ли, Hibernate как правило наботает в tier бизнесс-логики. У этого подхода есть преимущества в администрировании. Так что чего т так удивился я не особо понял.
A>>Сам то понял что написал?

A>ОМГ. У тебя есть две машины, на одной всё что на java, на воторой SQL-сервер. Это достаточно стандартная схема.

Все, что на Java... это простите что?

A>>Это sql, мы говорим о T-SQL и хранимках. типичный код хранимки не декларативный и представляет из себя жёское процедурное программирование

A>Это какая-то неправильная хранимка, она значит что-то лишнее делает.

Это уже не смешно... Вы это серьезно говорите?

A>>Что понимается по как попало объясните пожалуйста, а то я начинаю терять нить изложения

.

A>Как попало обозначает "без виденья общей структуры БД, включая проведённые денормализации, кеширования и т.п.".
A>Нужно было работать с пользователями, прочитал документацию только про табличку Users, но не прочитал про таблички так или иначе с ней связанные и как следствие нарушил целостность данных некорерктными действиями.

Потому и нужен ORM.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>ОМГ. У тебя есть две машины, на одной всё что на java, на воторой SQL-сервер. Это достаточно стандартная схема.
C>>У меня вот два сервера БД (кластер с failover) и 3 app-сервера в качестве front-end'ов. Все прекрасно работает с Hibernate.

A>Почетай выше о чём вообще речь, kuj совсем не понимает чем транзакции уровня БД отличаются от транзакций уровня бизнес-логики.

Транзакции уровня бизнес-логики? Вот это круто. Вы это только что придумали?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>Кстати говоря, SQL это ни разу не декларативный язык.

A>Сильно. Я это сообщение добавлю в favorites в раздел Юмор, можно?

Вам все можно! Заодно добавьте всю эту ветку. У вас что ни пост — перл!

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, adontz, Вы писали:

A>>>>ОМГ. У тебя есть две машины, на одной всё что на java, на воторой SQL-сервер. Это достаточно стандартная схема.
C>>>У меня вот два сервера БД (кластер с failover) и 3 app-сервера в качестве front-end'ов. Все прекрасно работает с Hibernate.

A>>Почетай выше о чём вообще речь, kuj совсем не понимает чем транзакции уровня БД отличаются от транзакций уровня бизнес-логики.

kuj>Транзакции уровня бизнес-логики? Вот это круто. Вы это только что придумали?
Ну на самом деле понятие бизнес транзакций вроде есть, но оно близко к понятию сферического коня в вакууме

. Вобщем никакого отношения к тому что говорит наш общий друг — любитель хранимок — не имеет

Здравствуйте, kuj, Вы писали:

A>>>Это sql, мы говорим о T-SQL и хранимках. типичный код хранимки не декларативный и представляет из себя жёское процедурное программирование

A>>Это какая-то неправильная хранимка, она значит что-то лишнее делает.
Многоуважаемый adontz. Язык T-SQL является процедурным языком. Может Вы имеете в виду вашу собственную разработу декларативного языка для СУБД?

Здравствуйте, adontz, Вы писали:

C>>Видимо, ты никогда не видел: http://tangosol.com/coherence-overview.jsp — кластерный транзакционный кэш, легко масштабируется на десятки машин (но стоит денег, сволочь). Сейчас используем тупой JBoss Cache — на кластере из пяти машин все спокойно живет, даже 100MBit не заполняет.

A>Этого действительно не видел. Суть проблемы это не меняет, неактуальный кеш — зло, эффективное поддержание кеша в актуальном состоянии — нетривиальная задача. Кстати ненасыщенность 100Мбит это не показатель. Сравнивать надо это с физическим ограничением сети, а с трафиком к клиентам.

Конечно это не тривиальная задача... Если программировать, используя такие средства, которые используете Вы. И вообще какое это все имеет отношение к кешу второго уровня Hibernate? Вы хоть знаете о чем ВООБЩЕ речь?

C>>Ага, такие вредные привычки как легкорефакторируемый код и запросы. Например, вот так умеет новая IDEA:
C>>

A>Нет, абсолютное забыванеи об индексах и представление, что объекты это точка отсчёта.

Ну вы хоть понимаете что такое индексы? А представления тут при чем?

Индексы строят под запросы, а не запросы под индексы.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

C>>Видимо, ты никогда не видел: http://tangosol.com/coherence-overview.jsp — кластерный транзакционный кэш, легко масштабируется на десятки машин (но стоит денег, сволочь). Сейчас используем тупой JBoss Cache — на кластере из пяти машин все спокойно живет, даже 100MBit не заполняет.

A>Этого действительно не видел. Суть проблемы это не меняет, неактуальный кеш — зло, эффективное поддержание кеша в актуальном состоянии — нетривиальная задача. Кстати ненасыщенность 100Мбит это не показатель. Сравнивать надо это с физическим ограничением сети, а с трафиком к клиентам.

Конечно это не тривиальная задача... Если программировать, используя такие средства, которые используете Вы. И вообще какое это все имеет отношение к кешу второго уровня Hibernate? Вы хоть знаете о чем ВООБЩЕ речь?

C>>Ага, такие вредные привычки как легкорефакторируемый код и запросы. Например, вот так умеет новая IDEA:
C>>

... << RSDN@Home 1.2.0 alpha rev. 746>>

Уважаемые, постарайтесь более уважительно относиться друг к другу, излагать свое мнение/опыт и отстаивать свои убеждения нужно достойно.

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

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>Видите ли, Ваша позиция напоминает программистов, которые в стародавние временна утверждали, что реальтный пацаны пишут на асме, где полный контроль машины, С для недоделанных. Дальше были дискуссии, что у Java/.NET нет будущего, на них приложения всегда будут проигрывать в эффективности С++... Время расставило всё на свои места.

A>Видишь ли, у меня много-много лет опыта работы за спиной и я знаю что панацеи нет и любая технология, самая хорошая вообще, обязательно облажается на какой-нибудь конкретной задаче. Hibernate это очень удобно и хорошо (кто бы спорил), но не всегда применимо. Без ХП писать можно, более того мелкие проекты нужно писать без ХП. В большинстве приложений не нужен MVC, достаточно Document-View. Вообще из пушки по воробьям стрелять не надо. Я реально сталкивался с задачами где реляционная модель и объекная раличались очень сильно и использоание ORM превращаось в мучение, в результате отказывались. Есть задачи не тестируемые автоматически в принципе, так что никакой TDD не спасёт. Вообще не надо верить в технологии, у них всегда есть область применения, зачастую довольно узкая.
Ну это прям лозунг для баррикад. И что же за такие проекты, для которых применения маппера оборачивается мучением?

TDD это не технология, это образ мышления. Если вы ищете спасение в TDD или ещё хз в чём, то может стоит задуматься о более тщательном проектировании, с оглядкой на то, как это делают сейчас, а не 10 лет назад? Тут как раз вопрос не столько о технологиях ( хотя и их надо тоже уметь своевременно менять ), а о образе мышленения, проектирования. Видишь ли, но с твоей тонной хранимок через несколько лет ты рискуешь оказаться единственным на поддержке понаписанного кода. И для мотивирования желания программистов этим заниматься придётся платить очень значительные деньги.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Cyberax, Вы писали:

C>>Нет. Спор о том, что из ХП часто делают poor-man's DAL, что более нормально делается более нормальными инструментами.

A>А я к этому не призывал. Охотиться на ведьм можете в другом месте

да, настоящие мужчины не пользуются инструментами, они всё делают плоскогубцами, молотком и напильником

Здравствуйте, adontz, Вы писали:

A>> Не надоело минусы ставить?

A>Минус выражает несогласие. В чём проблема? Если тебя это задевает лично, я могу убрать. Оценка вообще-то ставится сообщению, а не автору.
Проблем никаких, просто прикололо

A>>Не ну серьёзно, удивляет упорство, теперь я понимаю почему ты так защищаешь хранимки

A>ХП мне просто нравятся. Было долгое время, когда я писал без них. Я жестоко ошибался.

Ндя, когда все начали от них отходить, ты толко узнал что это такое

Здравствуйте, Kazna4ey, Вы писали:

K>Добрый вечер,

K>Я автор темы

K>Очень интересно читать Вашу беседу.
K>ОЧЕНЬ хотелось бы попросить, чтобы вы привели примеры кода, с разных уровней, т.е. как выглядит код в уровне GUI (в обработчиках кнопок например), этот код будет взаимодействовать с объектами из следующего уровня — приведите код из следующего уровня и т.д. Т.е. чтобы можно было кратко представить целую картину по оформлению работы с БД в приложении. А то сейчас все довольно абстрагировано, по крайней мере для меня — человека НЕ С ВАШИМ уровнем и опытом.
K>Это относится к обоим выделившимся сторонам обсуждения (Adontz и все остальные

.
Да лана пару примеров было, я даже четыре строки кода не поленился написать между прочим!

K>Дальше есть несколько вопросов:

K>1) Как реализации ORM будут работать с MySQL? Например в последнем приложении я использую MySQL. Т.е. вообще для какой СУБД генерируются запросы? Простите если чего-то не понимаю.
В конфиге Hibernate настраивается провайдер субд. Поддерживается mssql, firebird и ряд других субд, так что с запросами проблем не будет.

K>2) Что если у запроса есть много параметров, появление которых зависит от различных checkbox'ов или radiobox'ов на форме. Нет ли проблем в таких случаях? Я так понимаю что нет, т.к. в случае ORM запрос будет генерироваться на основе только выбранных параметров, а в случае с ХП используется dynamic sql?
В большинстве случаев будет удобно использовать Criteria. Это по сути конструктор запросов для хибернета, вот пример загрузки набора объектов с наложенными условиями из примеров к хибернету

IList cats = session.createCriteria(typeof(Cat))
    .Add( Restrictions.Like("name", "Fritz%") )
    .Add( Restrictions.Between("weight", minWeight, maxWeight) )
    .List();

K>3) Как проявляют себя 2 выделенные технологии на небольших-средних проектах (БД из 30 — 50 таблиц, есть маленькие таблицы, есть таблицы с миллионами записей)? Или на какого размера проекты ориентированы обсуждаемые подходы?
Это не имеет отношение к выбору подхода

K>4) Можно ли подробный пример действий, которые вы производите при модификации БД, например при добавлении/удалении столбца, или выноса нескольких столбцов в отдельную таблицу и замену их ключом (NewTableID) в оригинальной таблице?
При использовании Hibernate потребуется исправить чнебольшую часть XML, представляющего метаданные для отображения данного объекта в соответствующую таблицу.
Например вот что надо сделать в случае смены названия столбца Name->Name1
Исходный XML

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
namespace="DomainModel"
assembly ="DomainModel">

<class name="Stock" table="Stock" lazy="false">
<id name="Id">
<column name="id" sql-type="Int64" not-null="true"/>
<generator class="sequence">
<param name="sequence">gen_stockid</param>
</generator>
</id>

<property name="Name">
<column name="name"/>
</property>

</class>
</hibernate-mapping>

Новый XML

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
namespace="DomainModel"
assembly ="DomainModel">

<class name="Stock" table="Stock" lazy="false">
<id name="Id">
<column name="id" sql-type="Int64" not-null="true"/>
<generator class="sequence">
<param name="sequence">gen_stockid</param>
</generator>
</id>

<property name="Name">
<column name="name1"/>
</property>

</class>
</hibernate-mapping>

Больше изменений в проектах не требуется.

K>5) Я так понимаю что BLT, LINQ это все реализации ORM ?

Типа того. BLT — вобщем кустарная штука. Hibernate — один из признанных промышленных реализаций. LINQ — этот интеграция языка запросов и всей инфраструктуры ORM в компилятор языка, что позволяет получить проверку запроса на этапе компиляции. Плюс Linq унифицирует доступ к разнородным провайдерам даннх, т.е. к СУБД, коллекциям,...

K>Заранее большое спасибо.

Здравствуйте, adontz, Вы писали:

A>ХП мне просто нравятся. Было долгое время, когда я писал без них. Я жестоко ошибался.

Вы еще более жестоко ошибаетесь полагаясь на ХП.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Kazna4ey, Вы писали:

K>Я автор темы

.

Вот прекрасная статья про NHibernate и его применение в enterprise-приложениях.
http://www.codeproject.com/aspnet/NHibernateBestPractices.asp

Особое внимание обратите на раздел "Real-World Architecture".

K>Дальше есть несколько вопросов:

K>1) Как реализации ORM будут работать с MySQL? Например в последнем приложении я использую MySQL.
Hibernate поддерживает MySQL, если не ошибаюсь, все его версии.
K>Т.е. вообще для какой СУБД генерируются запросы? Простите если чего-то не понимаю.
Для субд, диалект которой был указан в конфигурации Hibernate.

Примерно так выглядит: NHibernate.Dialect.MsSql2005Dialect

K>2) Что если у запроса есть много параметров, появление которых зависит от различных checkbox'ов или radiobox'ов на форме. Нет ли проблем в таких случаях? Я так понимаю что нет, т.к. в случае ORM запрос будет генерироваться на основе только выбранных параметров, а в случае с ХП используется dynamic sql?
Все будет нормально.

И DataBinding на BLL-объектах прекрасно работает в .NET.

K>3) Как проявляют себя 2 выделенные технологии на небольших-средних проектах (БД из 30 — 50 таблиц, есть маленькие таблицы, есть таблицы с миллионами записей)? Или на какого размера проекты ориентированы обсуждаемые подходы?
Для небольших проектов я бы вообще посоветовал Castle ActiveRecord — это очень эффективная и качественная реализация патерна ActiveRecord на базе NHibernate.

http://www.castleproject.org/activerecord/gettingstarted/index.html

K>4) Можно ли подробный пример действий, которые вы производите при модификации БД, например при добавлении/удалении столбца, или выноса нескольких столбцов в отдельную таблицу и замену их ключом (NewTableID) в оригинальной таблице?
При такой постановке вопроса:
Модифицируем схему БД.
Модифицируем мэппинг
Модифируем DAL
Прогоняем уже готовые модульные тесты для DAL, чтоб убедиться, что все ок.
Если надо добавляем новые тесты.
Ну и далее по иерархии делается весь необходимый рефакторинг.

Хотя чаще все же начинаем с верхов и спускаемся вниз.

K>5) Я так понимаю что BLT, LINQ это все реализации ORM ?

Про BLT затрудняюсь сказать... LINQ это язык интегрированных запросов для объектов, XML и других форм данных.

Для NHibernate уже есть наработки, по интеграции его с LINQ, что не может не радовать.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Kazna4ey, Вы писали:

K>5) Я так понимаю что BLT, LINQ это все реализации ORM ?
Вот кстати по LINQ интересные webcast`ы:

http://download.microsoft.com/download/4/7/0/4703eba2-78c4-4b09-8912-69f6c38d3a56/linq.wmv

http://download.microsoft.com/download/4/7/0/4703eba2-78c4-4b09-8912-69f6c38d3a56/xlinq.wmv

http://download.microsoft.com/download/4/7/0/4703eba2-78c4-4b09-8912-69f6c38d3a56/dlinq.wmv

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, <Аноним>, Вы писали:

C>>>Нет. Спор о том, что из ХП часто делают poor-man's DAL, что более нормально делается более нормальными инструментами.

A>>А я к этому не призывал. Охотиться на ведьм можете в другом месте

А>да, настоящие мужчины не пользуются инструментами, они всё делают плоскогубцами, молотком и напильником

.

Зубами и когтями...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, MozgC, Вы писали:

MC>Уважаемые, постарайтесь более уважительно относиться друг к другу, излагать свое мнение/опыт и отстаивать свои убеждения нужно достойно.

MC>У меня самого опыт небольшой, поэтому мне в ваш спор лезть нельзя, какое-то время назад начал активно использовать ХП, сейчас в базе их в районе сотни — по крайней мере пока проблем нет. И действительно ХП я считаю нужно писать разумно. Сегодня на интервью приходил программист, у него в базе много ХП по несколько страниц. Я думаю что вот как раз в таком случае и могут возникнуть проблемы и с поддержкой и с пониманием. Имхо ХП надо делать относительно краткими, и не сваливать на них все что только можно.

А есть еще любители триггеров понавешивать куда попало. Там вообще жуткий кошмар...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>Да что вы говорите

. Вы статистику по проектам собирали или говорите на основании вашего горького опыта?

Уже даже не смешно...

A>Просто не только складским учётом занимаюсь.

С такими подходами Вас и к складскому учету подпускать нельзя...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>В общем случае иерархия объектов это НЕ данные. Ты разве не знал?
C>>Если не учитывать поведение объектов — всегда данные. Но не всегда красиво ложатся на реляционную модель.
A>Скажем так, объекты не всегда entities. В реляционную модельне укладываются очень часто. Увы.
А, кстати да. В Hibernate есть поддержка value objects для всяких мелочей типа координат и т.п. Можно определять свои типы (например, у меня enum'ы автоматически отображаются на строки). Так что и тут все нормально.

C>>Что значит "не вовремя"?
A>Не вовремя значит, что сперва сделали БД отражение иерархии объектов (по табличке на тип, по столбцу на поле) и решили что это хорошо. а потом вдруг выяснилось что так хранить данные крайне не эффективно. И начали не вовремя их менять. Вовремя, это если бы продумали БД с самого начала. То есть исходя из данных и операций, а не иерархии объектов.
А можно я?

"Сначала сделали базу по ER-диаграмме с крутыми оптимизациями. А потом выяснили, что bottleneck'и совсем в другом месте. Нужно было исходить из реалий бизнес-логики, а не структуры в ТЗ".

C>>Прекрасно — вот тебе колоночная DB на K. Писать программы тоже только на K. Будешь?
A>Что такое К?
Спроси в форуме "Декларативное программирование"

A>>>Нет, надо проектировать систему так, чтобы расширения функиональности не сопровождалось добавлением новых столбцов

C>>Это обычно нереально

A>Ну не каждый же чих...
Почему нет? Я предпочитаю рассматривать БД как инструмент, а не как идола, вокруг которого надо танцевать с бубном. Нужно что-то поменять в БД — делаем это.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, adontz, Вы писали:

A>>Ну давай мерятся пиписьками. На вот
A>>http://en.wikipedia.org/wiki/Object-relational_mapping
A>>Что я сказал не так?
C>Видимо, не использовал Hibernate в реальности

Кэш второго уровня там часто ускоряет работу в десятки раз, я об этом тут даже писал.
замечательно использовать нативный SQL. Только вот нужно это всего в процентах случаев.
Интересный факт, а есть ссылки по этой теме?

Здравствуйте, adontz, Вы писали:

A>Если тебе не совсем плевать на производительность, то да. Ты писал приложение, которое должно работать на MSSQL И MySQL? Это очень разные СУБД с разными заскоками. То что бегало на одной, на другой показывало просто УЖАСНУЮ производительность. Например в MySQL нет типа GUID, и если пойти на поводу у лени и хранить GUID'ы в строках, то получим падение производительности в разы. Разбиение на 4 int работало на ура, но никакая ORM не смогла это отобразить, что впрочем и не удивительно.
Это ты специально для раздела юмор вспомнил? Пишу из под стола

.

ЗЫ Если серьёзно, то это очередный аргумент, что связываться с mysql не стоит

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, adontz, Вы писали:

kuj>>>Человек говорит Вам о рефакторинге и об опечатках в колонках. Когда у вас сотни процедур с таким вот именем колонки жестко прописанным в каждой процедуре...
kuj>>>В случае с OR/M, поменяв имя колонки в базе, мне достаточно поменять его всего-лишь раз в файле мэпинга, а Вам придется перелопачивать все сотни процедур да еще и без стредств рефакторинга.

A>>Гуляй
A>>http://www.google.com/search?q=sql+refactoring+tools

kuj>Рефакторинг без юнит тестов? Удачи.
Сейчас в силу исторических причин делаю это на C#. Полная гамма острых ощущений

. А было время когда это не смущало...

Здравствуйте, Aviator, Вы писали:

C>>Видимо, не использовал Hibernate в реальности

Кэш второго уровня там часто ускоряет работу в десятки раз, я об этом тут даже писал.
C>>замечательно использовать нативный SQL. Только вот нужно это всего в процентах случаев.
A>Интересный факт, а есть ссылки по этой теме?
Про нативный SQL — в доке

Треды про кэширование:
http://www.rsdn.ru/Forum/?mid=2601691
Еще где-то было более подробное объяснение про наше приложение, но я его найти не могу

Здравствуйте, kuj, Вы писали:

MC>>У меня самого опыт небольшой, поэтому мне в ваш спор лезть нельзя, какое-то время назад начал активно использовать ХП, сейчас в базе их в районе сотни — по крайней мере пока проблем нет. И действительно ХП я считаю нужно писать разумно. Сегодня на интервью приходил программист, у него в базе много ХП по несколько страниц. Я думаю что вот как раз в таком случае и могут возникнуть проблемы и с поддержкой и с пониманием. Имхо ХП надо делать относительно краткими, и не сваливать на них все что только можно.
kuj>А есть еще любители триггеров понавешивать куда попало. Там вообще жуткий кошмар...
Триггеры, кстати, — вещь достаточно хорошая. Когда используются только для валидации данных.

Здравствуйте, kuj, Вы писали:

A>>Это миф. В реальной системе соответствие поле_класса<->колонка_таблицы встречается достааточно редко! Hibernate просто не в состоянии автоматически построить подобные запросы.
kuj>Кто вам эту чушь сказал?

Я это видел своими глазами.

Здравствуйте, kuj, Вы писали:

kuj>Интересно, а что мне помешает сделать то же самое в ORM? Думаете, я не смогу one-to-one relation в файле мэппинга прописать?

Я описал простейший случай, не надо включать дурака.

Здравствуйте, kuj, Вы писали:

A>>http://www.google.com/search?q=sql+refactoring+tools
kuj>Рефакторинг без юнит тестов? Удачи.

Мне вот интересно, что ты делаешь с нетестируемыми задачами?

Здравствуйте, Kazna4ey, Вы писали:

K>1) Как реализации ORM будут работать с MySQL? Например в последнем приложении я использую MySQL. Т.е. вообще для какой СУБД генерируются запросы? Простите если чего-то не понимаю.

Практически к любой ORM можно прикрутить поддержку практически любой БД.

K>2) Что если у запроса есть много параметров, появление которых зависит от различных checkbox'ов или radiobox'ов на форме. Нет ли проблем в таких случаях? Я так понимаю что нет, т.к. в случае ORM запрос будет генерироваться на основе только выбранных параметров, а в случае с ХП используется dynamic sql?

В случае с ХП делается несколько ХП, потому что это они в интерфейсе один разнообразный запрос, а для БД это много однообразных запросов.

K>3) Как проявляют себя 2 выделенные технологии на небольших-средних проектах (БД из 30 — 50 таблиц, есть маленькие таблицы, есть таблицы с миллионами записей)? Или на какого размера проекты ориентированы обсуждаемые подходы?

Количество таблиц/столбцов не показатель вообще говоря. Данные могут очень просто обрабатыватся и быть очень объёмными. Задача не становится от этого сложной.

K>4) Можно ли подробный пример действий, которые вы производите при модификации БД, например при добавлении/удалении столбца, или выноса нескольких столбцов в отдельную таблицу и замену их ключом (NewTableID) в оригинальной таблице?

Для ХПЖ
Перебираем все запросы так или иначе затрагивающие таблицу (список запросто получается автоматом) и смотрим нужно ли что-то там с этим столбцом сделать. Обычно нет, так как на запросе изменения имени добавление даты рождения не влияет.
Корректируем затронутые запросы.
Тестируем БД.
Подправляем DAL.
Тестируем DAL.

K>5) Я так понимаю что BLT, LINQ это все реализации ORM ?

И да и нет. Хотя формально BLT можно отнести к ORM, по функциональности и идеологии она от Hibernate & Co очень сильно отличается.

Здравствуйте, kuj, Вы писали:

kuj>Все, что на Java... это простите что?

Код, написанный на Java.

A>>Как попало обозначает "без виденья общей структуры БД, включая проведённые денормализации, кеширования и т.п.".
A>>Нужно было работать с пользователями, прочитал документацию только про табличку Users, но не прочитал про таблички так или иначе с ней связанные и как следствие нарушил целостность данных некорректными действиями.
kuj>Потому и нужен ORM.

ORM нужен для совсем других вещей, от дураков ORM ни спасает абсолютно.

Здравствуйте, kuj, Вы писали:

A>>Почетай выше о чём вообще речь, kuj совсем не понимает чем транзакции уровня БД отличаются от транзакций уровня бизнес-логики.

kuj>Транзакции уровня бизнес-логики? Вот это круто. Вы это только что придумали?

То есть у тебя не бывает транзакций на уровне бизнес-логики? Вау!!! И этот человек обвиняет меня в невежестве.

Здравствуйте, Aviator, Вы писали:

A>>>Это какая-то неправильная хранимка, она значит что-то лишнее делает.
A>Многоуважаемый adontz. Язык T-SQL является процедурным языком. Может Вы имеете в виду вашу собственную разработу декларативного языка для СУБД?

SQL это декларативный язык. T-SQL декларативный язык с императивными элементами. Процедурный язык, это императивный язык без элементов ООП. То есть если бы T-SQL был процедурным, то ты бы писал не SQL-выражения, а планы запросов. Для начала разберись с терминологией, иначе общаться невозможно.

Здравствуйте, kuj, Вы писали:

kuj>Конечно это не тривиальная задача... Если программировать, используя такие средства, которые используете Вы. И вообще какое это все имеет отношение к кешу второго уровня Hibernate? Вы хоть знаете о чем ВООБЩЕ речь?

Этот вопрос ты используешь как средство дискутирвовать? Риторические вопросы задают тогда, когда нет ответов на актуальные. Ты не смог сказать ничего существенного про ХП, кроме того что "ХП процедуры сложно читать, они занимают несколько экранов". Вообще-то процедуры на несколько экранов сложно читать вне зависимости от языка. но в этой теме ты не силён, куда проще воздеть руки к небу и крукнуть "куда катится мир?". Давай не скатывайся в демагогию, если есть что сказать по существу, с примерами хороших и плохих ситуаций, то я жду. Если нет, не заставляй тратить время на чтение быссмысленных сообщений.

A>>Нет, абсолютное забыванеи об индексах и представление, что объекты это точка отсчёта.
kuj>Ну вы хоть понимаете что такое индексы? А представления тут при чем?

Ага, значит и русского мы не знаем. В данном случае слово представление было употреблено в смысле "образ виденья", а не как калька термина "view".

kuj>Индексы строят под запросы, а не запросы под индексы.

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

Здравствуйте, Aviator, Вы писали:

A>Ну это прям лозунг для баррикад. И что же за такие проекты, для которых применения маппера оборачивается мучением?

TDD это не технология, это образ мышления.

Есть не тестируемые задачи, как же ты бедненький о них думаешь? Технологии служат разработчику, а не наоборот, не забыл?

Здравствуйте, Aviator, Вы писали:

A>Ндя, когда все начали от них отходить, ты толко узнал что это такое

.

Да нет, уж года 4. Что-то пока не разочаровался.

Здравствуйте, Cyberax, Вы писали:

C>А, кстати да. В Hibernate есть поддержка value objects для всяких мелочей типа координат и т.п. Можно определять свои типы (например, у меня enum'ы автоматически отображаются на строки). Так что и тут все нормально.

Это всё не то. Например может быть ситуация когда у меня массив некоторых состояний (скажем Boolean, хотя может быть и enum или даже разные enum'ы) и я имею действия для всех (или почти всех) вариантов. В приложении я делаю массив с выводом индекса из состояний, потому что это обеспефивает время доступа О(1), по сравнению с map<state_array, action> и O(log(N)). В БД у меня нет никакого массива, надо как-то иначе изворачиватся. То есть тут речь идёт об отображении не единичного объекта или поля, а коллекции. Бывают и более сложные случаи.

C>"Сначала сделали базу по ER-диаграмме с крутыми оптимизациями. А потом выяснили, что bottleneck'и совсем в другом месте. Нужно было исходить из реалий бизнес-логики, а не структуры в ТЗ".

Нет, никаких кртых оптимизаций с начала не будет, будет draft. Главное чтобы в нём хранились данные, а не объекты.

C>>>Прекрасно — вот тебе колоночная DB на K. Писать программы тоже только на K. Будешь?
A>>Что такое К?
C>Спроси в форуме "Декларативное программирование"

Буду честен — лень.

A>>Ну не каждый же чих...
C>Почему нет?

Потому что это говорит об очень не гибкой схеме БД. Это плохо. Дело не в том чтобы намеренно не трогать БД, а в том чтобы БД действительно не надо было трогать.

Здравствуйте, Aviator, Вы писали:

A>Это ты специально для раздела юмор вспомнил? Пишу из под стола

.

Ну да, вам смешно, а мне работать

A>ЗЫ Если серьёзно, то это очередный аргумент, что связываться с mysql не стоит

.

100%. Но его бесплатность и популярность делают своё чёрное дело. Я вообще не думаю, что после выхода Express версий с чем-то кроме MSSQL/Oracle стоит связываться. Себе дороже.

Здравствуйте, kuj, Вы писали:

kuj>А есть еще любители триггеров понавешивать куда попало. Там вообще жуткий кошмар...

У меня создаётся впечатление что ты хаешь просто всё с чем не разобрался.

Народ, мне лень уже. Ничего нового сказано уже, наверное, не будет.
Спасибо Cyberax, как единственному опоненту с которым было интересно поболтать. Я может в чём-то и не согласен, но он по крайней мере не фанатик.
Остальным тоже спасибо, было весело.
Всем удачного вторника.

Здравствуйте, kuj, Вы писали:

kuj>Есть такое понятие, как сроки, и к сожалению сроки всегда ограничены. Как Вы думаете, зачем был придуман .NET Framework и Java? Можно было бы и на ASM писать... — все контроллировать и быть увереными (быть ли?), что не потеряли производительности и контролируют процесс.

Я не ратую за то, что бы писали на ASM-е, просто хочется заметить что есть разные подходы, и если Вы используете один из них это не значит, что он всегда и везде самый лучший. Есть разные точки зрения, каждый придерживается той, которая ему ближе.
По поводу, того зачем были придуманы .Net Framework или Java — думаю для того, чтобы облегчить разрабочикам жизнь, а может чтобы просто двум компаниям, не будем показывать на них пальцем, перетянуть на свою платформу разработчиков да и денег подзаработать

kuj>Гораздо легче. Даже, если написано через пень-колоду, все-равно гораздо легче.

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

...

"Вы не любите кошек? Вы просто не умеете их готовить" ©не помню кто сказал...
Для разных людей будут удобнее разные вещи. Если Вам удобней организовывать тестирование кода на с#, это не значит что всем именно это удобнее.

Здравствуйте, adontz, Вы писали:

C>>А, кстати да. В Hibernate есть поддержка value objects для всяких мелочей типа координат и т.п. Можно определять свои типы (например, у меня enum'ы автоматически отображаются на строки). Так что и тут все нормально.
A>Это всё не то. Например может быть ситуация когда у меня массив некоторых состояний (скажем Boolean, хотя может быть и enum или даже разные enum'ы) и я имею действия для всех (или почти всех) вариантов. В приложении я делаю массив с выводом индекса из состояний, потому что это обеспефивает время доступа О(1), по сравнению с map<state_array, action> и O(log(N)).
Не понял сути. Можно подробнее немного?

A>В БД у меня нет никакого массива, надо как-то иначе изворачиватся. То есть тут речь идёт об отображении не единичного объекта или поля, а коллекции. Бывают и более сложные случаи.
Если в поле оно у нас не помещается — то тогда делаем зависимую таблицу. По-другому особо не получится. Ну или битовые поля — по ним даже индексы строятся.

C>>"Сначала сделали базу по ER-диаграмме с крутыми оптимизациями. А потом выяснили, что bottleneck'и совсем в другом месте. Нужно было исходить из реалий бизнес-логики, а не структуры в ТЗ".
A>Нет, никаких кртых оптимизаций с начала не будет, будет draft. Главное чтобы в нём хранились данные, а не объекты.
А ты представь, что каждая строка таблицы — это экземпляр объекта

Просто draft и с моим сценарием точно так же делается, с точно такими же возможностями облома в реальных боевых условиях.

C>>Спроси в форуме "Декларативное программирование"

A>Буду честен — лень.
Ну в общем, если кратко — то программы на K выглядят примерно вот так: "(!R)@&{&/x!/:2_!x}'!R". Но на нем написана одна из самых быстрых "колоночных" баз данных.

A>>>Ну не каждый же чих...
C>>Почему нет?
A>Потому что это говорит об очень не гибкой схеме БД. Это плохо. Дело не в том чтобы намеренно не трогать БД, а в том чтобы БД действительно не надо было трогать.
Гибкость, естественно, должна быть — при рефакторингах схемы деструктивные изменения абсолютно недопустимы. Но с другой стороны, когда-то схему менять все равно придется.

Здравствуйте, adontz, Вы писали:

A>>>http://www.google.com/search?q=sql+refactoring+tools
kuj>>Рефакторинг без юнит тестов? Удачи.

A>Мне вот интересно, что ты делаешь с нетестируемыми задачами?

При чем тут нетестируемые задачи? Речь о юнит тестах. Вы не знаете что это такое?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Почетай выше о чём вообще речь, kuj совсем не понимает чем транзакции уровня БД отличаются от транзакций уровня бизнес-логики.

kuj>>Транзакции уровня бизнес-логики? Вот это круто. Вы это только что придумали?

A>То есть у тебя не бывает транзакций на уровне бизнес-логики? Вау!!! И этот человек обвиняет меня в невежестве.

Бизнес-логика ничего. Абсолютно ничего о транзакциях знать не должна. Для этого есть DAL, который управляет транзакциями, где это необходимо.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>>Это какая-то неправильная хранимка, она значит что-то лишнее делает.
A>>Многоуважаемый adontz. Язык T-SQL является процедурным языком. Может Вы имеете в виду вашу собственную разработу декларативного языка для СУБД?

A>SQL это декларативный язык. T-SQL декларативный язык с императивными элементами.
A>Процедурный язык, это императивный язык без элементов ООП. То есть если бы T-SQL был процедурным, то ты бы писал не SQL-выражения, а планы запросов. Для начала разберись с терминологией, иначе общаться невозможно.

Супер. Это можно сразу в юмор.

5 баллов!

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Как попало обозначает "без виденья общей структуры БД, включая проведённые денормализации, кеширования и т.п.".
A>>>Нужно было работать с пользователями, прочитал документацию только про табличку Users, но не прочитал про таблички так или иначе с ней связанные и как следствие нарушил целостность данных некорректными действиями.
kuj>>Потому и нужен ORM.

A>ORM нужен для совсем других вещей, от дураков ORM ни спасает абсолютно.

И Вы уже знаете для чего нужен ORM?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

K>>1) Как реализации ORM будут работать с MySQL? Например в последнем приложении я использую MySQL. Т.е. вообще для какой СУБД генерируются запросы? Простите если чего-то не понимаю.

A>Практически к любой ORM можно прикрутить поддержку практически любой БД.

Ну-ну...

K>>4) Можно ли подробный пример действий, которые вы производите при модификации БД, например при добавлении/удалении столбца, или выноса нескольких столбцов в отдельную таблицу и замену их ключом (NewTableID) в оригинальной таблице?

A>Для ХПЖ
A>Перебираем все запросы так или иначе затрагивающие таблицу (список запросто получается автоматом) и смотрим нужно ли что-то там с этим столбцом сделать. Обычно нет, так как на запросе изменения имени добавление даты рождения не влияет.
A>Корректируем затронутые запросы.

A>Тестируем БД.

На этом пункте подробнее пожалуйста. Как и чем Вы тестируете БД?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>Интересно, а что мне помешает сделать то же самое в ORM? Думаете, я не смогу one-to-one relation в файле мэппинга прописать?

A>Я описал простейший случай, не надо включать дурака.

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

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Это миф. В реальной системе соответствие поле_класса<->колонка_таблицы встречается достааточно редко! Hibernate просто не в состоянии автоматически построить подобные запросы.
kuj>>Кто вам эту чушь сказал?

A>Я это видел своими глазами.

Ну давайте уж конкретный пример, раз Вы это "видели своими глазами". Я думаю нам всем будет интересно посмотреть...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Cyberax, Вы писали:

A>>Это всё не то. Например может быть ситуация когда у меня массив некоторых состояний (скажем Boolean, хотя может быть и enum или даже разные enum'ы) и я имею действия для всех (или почти всех) вариантов. В приложении я делаю массив с выводом индекса из состояний, потому что это обеспефивает время доступа О(1), по сравнению с map<state_array, action> и O(log(N)).
C>Не понял сути. Можно подробнее немного?

Анкета медицинского обследования

Пол? [Мужской] [Женский]
Рука дёргается? [Да] [Иногда] [Нет]
Глаза слезятся? [Да] [Иногда] [Нет]

получаем 2*3*3 = 18 вариантов. Итого имеем 18 вариантов реакции (текст в рекомендациями). В программе снимок текущей системы вопросов в виде List<Diagnoses>, в БД этого естествено нет. Список вопросов не статичный, со временем может менятся их набор, порядок, варианты ответов. То есть хранить БД всё в таблице (int, string) не получается.

Здравствуйте, kuj, Вы писали:

Ты меня утомил, отстань и делай что хочешь. Пока мы работаем не вместе, мне плевать.

Здравствуйте, ilvi, Вы писали:

kuj>>Есть такое понятие, как сроки, и к сожалению сроки всегда ограничены. Как Вы думаете, зачем был придуман .NET Framework и Java? Можно было бы и на ASM писать... — все контроллировать и быть увереными (быть ли?), что не потеряли производительности и контролируют процесс.

I>Я не ратую за то, что бы писали на ASM-е, просто хочется заметить что есть разные подходы, и если Вы используете один из них это не значит, что он всегда и везде самый лучший.

Мы говорим о корпоративных БД? Для корпоративных БД ORM подход зарекомендовал себя как лучший на протяжении уже многих лет в тысячах, в десятках тысяч проектов по всему миру.

I>По поводу, того зачем были придуманы .Net Framework или Java — думаю для того, чтобы облегчить разрабочикам жизнь, а может чтобы просто двум компаниям, не будем показывать на них пальцем, перетянуть на свою платформу разработчиков да и денег подзаработать

Особенно смешно это читать про Java... Еще один перл в коллекции.

kuj>>Гораздо легче. Даже, если написано через пень-колоду, все-равно гораздо легче.

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

В том то и дело, что самые кривые ORM проекты поддаются рефакторингу куда лучше, чем проекты на ХП.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>А есть еще любители триггеров понавешивать куда попало. Там вообще жуткий кошмар...

A>У меня создаётся впечатление что ты хаешь просто всё с чем не разобрался.

Просто у меня опыта очевидно больше, чем у Вас.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>Индексы строят под запросы, а не запросы под индексы.

A>Подобные категоричные заявления вызывают у меня смех. На все случаи жизни индексы не построишь, обновление индекса не бесплатная операция.

Я же Вам уже говорил, что расстановка индексов задача тривиальная, если СУБД предоставляет статистику. Анализируете переодически данную статистику и определяете какие индексы надо добавить, а какие лучше выкинуть. Ничего тут фантастически сложного нету.

Вот читайте и просвещайтесь на примере MS SQL Server:

http://www.microsoft.com/technet/scriptcenter/scripts/sql/sql2005/index/default.mspx?mfr=true

и зачем я ввязался в этот спор и трачу время на абсолютно неграмотных типов...

A>Иногда надо и запрос подправить. Нет тут ничего зазорного. Вообще в том чтобы думать своей головой исходя из ситуации, а не догматично применять некоторый, возмодно неадекватный, метод решения проблемы нет ничего зазорного.

Да уж. Вы явно специалист по неадекватным методам решений проблемы.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>Просто у меня опыта очевидно больше, чем у Вас.

Да мне и в плане высосомерия до тебя далеко.

Здравствуйте, ilvi, Вы писали:

A>>просто писать юнит тесты на каком нить c# с заглушками намного проще чем организовывать автоматическое тестирование кода совместно с субд

...

I>"Вы не любите кошек? Вы просто не умеете их готовить" ©не помню кто сказал...
I>Для разных людей будут удобнее разные вещи. Если Вам удобней организовывать тестирование кода на с#, это не значит что всем именно это удобнее.

Ну может расскажете или хотя бы ссылку на ресурс дадите о тестировании ХП в СУБД?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>Ты меня утомил, отстань и делай что хочешь. Пока мы работаем не вместе, мне плевать.

Значит ответить на вопрос как и чем Вы тестируете БД не можем никак? Все понятно.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>Просто у меня опыта очевидно больше, чем у Вас.

A>Да мне и в плане высосомерия до тебя далеко.

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

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

A>>Ты меня утомил, отстань и делай что хочешь. Пока мы работаем не вместе, мне плевать.
kuj>Значит ответить на вопрос как и чем Вы тестируете БД не можем никак? Все понятно.

Нет, значит ты меня утомил. Не надо искать всемирный заговор там, где его нет. Ты задаёшь глупые вопросы, пересказываешь лозунги, но сам по сути ничего существенного кроме "ОRМ-рулят" не сказал. Все тво комментарии сводятся к "ну-ну" и "вы вообще знаете?". Мне такая дискуссия не интересна, она скучна и утомительна. Я не буду отвечать на твои вопросы не потому что нет ответов, а потому что меня не интересуют твои вопросы.

Здравствуйте, kuj, Вы писали:

A>>Да мне и в плане высосомерия до тебя далеко.
kuj>В плане знаний и опыта очевидно тоже. Я надеюсь, что хоть после этого спора Вы узнали для себя много новых слов?

Я изучаю значения слов, а не звучание. Ты несколько раз употребил слово масштабируемость совершенно не в тему. Я полагаю, что ты считаешь свои сообщения более умными если там есть умное слово. Это не так.
Вобщем завязывай. Я привёл и примеры ошибочных действий в случае когда нет ХП и примеры данных для которых реляционная и объектная модель сильно различаются и вообще много чего существенного сказал. Ты же толчёшь воду в ступе. В твоих сообщениях нет решительно ничего полезного. Охи и вздохи оставь себе, мне их случать не интересно.

Здравствуйте, adontz, Вы писали:

A>Я изучаю значения слов, а не звучание. Ты несколько раз употребил слово масштабируемость совершенно не в тему. Я полагаю, что ты считаешь свои сообщения более умными если там есть умное слово. Это не так.
A>Вобщем завязывай. Я привёл и примеры ошибочных действий в случае когда нет ХП и примеры данных для которых реляционная и объектная модель сильно различаются и вообще много чего существенного сказал. Ты же толчёшь воду в ступе. В твоих сообщениях нет решительно ничего полезного. Охи и вздохи оставь себе, мне их случать не интересно.

Где? Примеры где?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Ты меня утомил, отстань и делай что хочешь. Пока мы работаем не вместе, мне плевать.
kuj>>Значит ответить на вопрос как и чем Вы тестируете БД не можем никак? Все понятно.

A>Нет, значит ты меня утомил. Не надо искать всемирный заговор там, где его нет. Ты задаёшь глупые вопросы, пересказываешь лозунги, но сам по сути ничего существенного кроме "ОRМ-рулят" не сказал. Все тво комментарии сводятся к "ну-ну" и "вы вообще знаете?". Мне такая дискуссия не интересна, она скучна и утомительна. Я не буду отвечать на твои вопросы не потому что нет ответов, а потому что меня не интересуют твои вопросы.

Рекомендую в будущем не ввязываться в спор, если не имеете представления о предмете спора, чтоб не выставлять себя клоуном, как это случилось в этом топике.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>Где? Примеры где?

http://www.rsdn.ru/Forum/message/2667683.1.aspx
http://www.rsdn.ru/Forum/message/2669221.1.aspx

Здравствуйте, kuj, Вы писали:

kuj>Мы говорим о корпоративных БД? Для корпоративных БД ORM подход зарекомендовал себя как лучший на протяжении уже многих лет в тысячах, в десятках тысяч проектов по всему миру.

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

kuj>Особенно смешно это читать про Java... Еще один перл в коллекции.

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

Здравствуйте, adontz, Вы писали:

C>>Не понял сути. Можно подробнее немного?
A>Анкета медицинского обследования
A>Пол? [Мужской] [Женский]
A>Рука дёргается? [Да] [Иногда] [Нет]
A>Глаза слезятся? [Да] [Иногда] [Нет]
A>получаем 2*3*3 = 18 вариантов.
A>Итого имеем 18 вариантов реакции (текст в рекомендациями). В программе снимок текущей системы вопросов в виде List<Diagnoses>, в БД этого естествено нет. Список вопросов не статичный, со временем может менятся их набор, порядок, варианты ответов. То есть хранить БД всё в таблице (int, string) не получается.
Ага, ты нашел самую гадостную для РБД вещь

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

На РБД это можно сделать таким образом:
1) Если список вопросов достаточно статичный — то просто делаем таблицу с колонкой на каждый вопрос. Набор колонок отображаем в List<Diagnosis> в DAL. Самое быстрое решение будет, кстати. Но при добавлении вопроса — придется менять схему.
2) Делаем полиморфное отношение с join-таблицами и полем-дискриминатором. Масштабироваться будет достаточно неплохо, но не неограничено.
3) Если набор типов вариантов ответа и типов вопроса ограничен — то делаем простую табличку:

CREATE TABLE "public"."question" (
  "id" BIGINT NOT NULL, 
  "question_id" BIGINT, 
  "answer_id" BIGINT, 
  CONSTRAINT "question_pkey" PRIMARY KEY("id")
);

Где question_id — ссылка на сущность в словаре запросов (тут тоже хорошо полиморфные отношения подойдут), а answer_id — ссылка на ответ.
4) Комбинированое решение — самые частые вопросы добавлять в таблицу колонками, а экзотику — в виде дополнительных отношений.
5) Завтра еще у нашего DBA спрошу что еще можно сделать

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>>>Это какая-то неправильная хранимка, она значит что-то лишнее делает.
A>>Многоуважаемый adontz. Язык T-SQL является процедурным языком. Может Вы имеете в виду вашу собственную разработу декларативного языка для СУБД?

A>SQL это декларативный язык. T-SQL декларативный язык с императивными элементами. Процедурный язык, это императивный язык без элементов ООП. То есть если бы T-SQL был процедурным, то ты бы писал не SQL-выражения, а планы запросов. Для начала разберись с терминологией, иначе общаться невозможно.
Я нифига понял из написанного

. То есть в С все пишут планы запросов или это декларативный язык?

Здравствуйте, adontz, Вы писали:

A>>ЗЫ Если серьёзно, то это очередный аргумент, что связываться с mysql не стоит

.

A>100%. Но его бесплатность и популярность делают своё чёрное дело. Я вообще не думаю, что после выхода Express версий с чем-то кроме MSSQL/Oracle стоит связываться. Себе дороже.
Тебя может это удивить, но ещё есть такие вещи, как Firebird

Здравствуйте, adontz, Вы писали:

kuj>>Где? Примеры где?

A>http://www.rsdn.ru/Forum/message/2667683.1.aspx

Прекрасный пример! В котором Вы предлагаете индексировать поле password (перл!), а потом приводите пример процедур, которые в виде методов должны находиться в DAL.

A>http://www.rsdn.ru/Forum/message/2669221.1.aspx

Еще один чудесный пример. Называется "я ничего не знаю про словари и кеш второго уровня Hibernate".

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

A>>Нет, значит ты меня утомил. Не надо искать всемирный заговор там, где его нет. Ты задаёшь глупые вопросы, пересказываешь лозунги, но сам по сути ничего существенного кроме "ОRМ-рулят" не сказал. Все тво комментарии сводятся к "ну-ну" и "вы вообще знаете?". Мне такая дискуссия не интересна, она скучна и утомительна. Я не буду отвечать на твои вопросы не потому что нет ответов, а потому что меня не интересуют твои вопросы.

kuj>Рекомендую в будущем не ввязываться в спор, если не имеете представления о предмете спора, чтоб не выставлять себя клоуном, как это случилось в этом топике.

Не надо принимать делаемое за действительное. На протяжении всего спора ты нёс полнеёший бред, начав с того что спор использовать или нет SP, ты перевёл в русло ORM vs SP. Все твои аргументы сводились к тому что я якобы чего-то не знаю, хотя "правильную" точку зрения ты так и не смог сформулировать. Хотя, конечно, заявления что SQL не декларативный язык и что бизнес-транзакций не существует ещё надолго запомнятся. Я понимаю, когда люди спорят о чём-то новом и не известном, но когда начинают определять факты данные по определению это просто утомляет.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Kazna4ey, Вы писали:

K>>1) Как реализации ORM будут работать с MySQL? Например в последнем приложении я использую MySQL. Т.е. вообще для какой СУБД генерируются запросы? Простите если чего-то не понимаю.

A>Практически к любой ORM можно прикрутить поддержку практически любой БД.
Да, може тогда поможете мне прикрутить поддержку диалекта FB к одному из симпатичных мапперов без данной поддержки?

Здравствуйте, Aviator, Вы писали:

A>>>>>Это какая-то неправильная хранимка, она значит что-то лишнее делает.
A>>>Многоуважаемый adontz. Язык T-SQL является процедурным языком. Может Вы имеете в виду вашу собственную разработу декларативного языка для СУБД?

A>>SQL это декларативный язык. T-SQL декларативный язык с императивными элементами. Процедурный язык, это императивный язык без элементов ООП. То есть если бы T-SQL был процедурным, то ты бы писал не SQL-выражения, а планы запросов. Для начала разберись с терминологией, иначе общаться невозможно.
A>Я нифига понял из написанного

. То есть в С все пишут планы запросов или это декларативный язык?

С это очевидно Непонятно хто с императивными элементами.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Cyberax, Вы писали:

C>Ага, ты нашел самую гадостную для РБД вещь

Она меня сама нашла несколько лет назад. Причём меня тогда поразило то что я не то чтобы не смог с наскоку сделать хоть как-то, а то что я с наскоку вообще ничего не смог сделать. Пришлось задуматся. А потом я начал понимать, что БД и объекты совсем разные вещи и разрабатывать их надо отдельно.

C>2) Делаем полиморфное отношение с join-таблицами и полем-дискриминатором. Масштабироваться будет достаточно неплохо, но не неограничено.

Ну вот что-то типа этого и внедрили в итоге. Мне вообще такие гадостные вещи попадаются достаточно часто. Наверное я неудачник и пока все остальные счастливы на стандартных, легко отображаемых задачах, я ломаю голову над своими плохо отображаемыми

Но подход независимой разработки БД выработался.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kuj, Вы писали:

A>>>Ты меня утомил, отстань и делай что хочешь. Пока мы работаем не вместе, мне плевать.
kuj>>Значит ответить на вопрос как и чем Вы тестируете БД не можем никак? Все понятно.

A>Нет, значит ты меня утомил. Не надо искать всемирный заговор там, где его нет. Ты задаёшь глупые вопросы, пересказываешь лозунги, но сам по сути ничего существенного кроме "ОRМ-рулят" не сказал. Все тво комментарии сводятся к "ну-ну" и "вы вообще знаете?". Мне такая дискуссия не интересна, она скучна и утомительна. Я не буду отвечать на твои вопросы не потому что нет ответов, а потому что меня не интересуют твои вопросы.
Был задан очень хороший и вполне конкретный вопрос. Причём этот вопрос задавался неоднократно по этой теме. Ты сказал что тестируешь ХП и БД. Общественность заинтересовалась как ты это делаешь. У меня вот, например, так и не получилось

, так что я с удовольствием почитаю как.

Здравствуйте, kuj, Вы писали:
kuj>Бизнес-логика ничего. Абсолютно ничего о транзакциях знать не должна. Для этого есть DAL, который управляет транзакциями, где это необходимо.
Ну, лично мне это странно слышать. Есть, конечно, "технические" транзакции (типа коммит после каждой записи лога, чтобы обеспечить максимум информации в случае сбоя), но в основном "ноги" у транзакций растут именно из бизнеса. Сам бизнес рассматривается как набор процессов, которые представляют собой цепочки транзакций.
При этом в бизнес-транзакцию в отличие от того, что происходит по begin tran, может включаться много всяких ресурсов. Например, транзакция "обработка заказа" может включать в себя, помимо записи чего-то в базу, поиск товара на складе, упаковку его в тару и передачу в транспортную компанию, а также отправку емейла. И всё это должно удовлетворять требованиям ACID. Именно бизнес определяет, не поделить ли этот процесс на другие транзакции — например, для оптимизации выделить передачу в транспортную компанию в отдельную транзакцию.

Вот мне как-то всегда казалось, что уровень Апп-сервера должен оперировать как раз такими высокоуровневыми транзакциями, управляя "техническими" транзакциями по мере необходимости.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, adontz, Вы писали:

A>>SQL — декларативный язык.

kuj>Кстати говоря, SQL это ни разу не декларативный язык. SQL это информационно-логический язык и по-сути он не является языком программирования. SQL это структурированный язык запросов.
kuj>Декларативный язык это, например, Prolog.
Я с вас обоих угораю.
Пришли значит, две генеральские жены в оперу. Отслушали первый акт. Первая:
— Нет, это просто фураж!
Вторая:
— Ты что, дура? Не фураж, а террор!

Декларативность языка, говоря неформально — это описание того, что нужно получить, а не как.
В этом смысле и Пролог, и SQL вполне себе декларативны.

Более того, Пролог тоже является информационно-логическим языком, если говорить о более формальной классификации.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, adontz, Вы писали:

A>Народ, мне лень уже. Ничего нового сказано уже, наверное, не будет.
A>Спасибо Cyberax, как единственному опоненту с которым было интересно поболтать. Я может в чём-то и не согласен, но он по крайней мере не фанатик.
A>Остальным тоже спасибо, было весело.
A>Всем удачного вторника.
тебе тож спасибо, ты был на высоте. давно я так не смеялся от души

Здравствуйте, ilvi, Вы писали:

kuj>>Мы говорим о корпоративных БД? Для корпоративных БД ORM подход зарекомендовал себя как лучший на протяжении уже многих лет в тысячах, в десятках тысяч проектов по всему миру.

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

В наше время? Готов поспорить, что нет, а те что есть в основном пережитки далекого прошлого.

I>Не буду спорить с тем что использывать ORM легче и приятней для многих людей, надо просто трезво смотреть на вещи. У каждого подхода своя ниша. И как бы Вам это не нравилось, как бы этого не хотелось маркетолагам, проталкивающим новые технологии, но по моему мнению использование хранимых процедур все еще не решено смысла.

kuj>>Особенно смешно это читать про Java... Еще один перл в коллекции.

I>Вы думаете на открытых проектах нельзя зарабатывать деньги? Вы действительно думаете, что большие корпарации в первую очередь думают о конкректных программистнах, которых они знать не знают?

Вы знаете как зарабатывать деньги на открытых проектах? Поделитесь знаниями! :D

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Aviator, Вы писали:

A>>SQL это декларативный язык. T-SQL декларативный язык с императивными элементами. Процедурный язык, это императивный язык без элементов ООП. То есть если бы T-SQL был процедурным, то ты бы писал не SQL-выражения, а планы запросов. Для начала разберись с терминологией, иначе общаться невозможно.
A>Я нифига понял из написанного

. То есть в С все пишут планы запросов или это декларативный язык?

SQL — это декларативный язык. Ты описываешь не КАК делать, а ЧТО делать. Не способ получения конечного результата, а сам результат.

T-SQL это декларативный язык (старое-то не выкинули) с императивными элементами (новое добавили). То есть в некоторых случаях ты теперь можешь описать КАК получить результат. Причём это не замена уже существующим механизмам, а дополнение.

Наследования в каком-либо виде в T-SQL нет, пространств имён или класов — тоже. Императивная часть T-SQL не объектно-ориентирована, она процедурная.

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

Не знаю как ещё выразить свою мысль. Лучше конкретные вопросы задавай.

Здравствуйте, kuj, Вы писали:

A>>http://www.rsdn.ru/Forum/message/2669221.1.aspx
kuj>Еще один чудесный пример. Называется "я ничего не знаю про словари и кеш второго уровня Hibernate".

Чудно. А теперь покажи мне решение с кешом второго уровня. Я жду.

Здравствуйте, Sinclair, Вы писали:

kuj>>Бизнес-логика ничего. Абсолютно ничего о транзакциях знать не должна. Для этого есть DAL, который управляет транзакциями, где это необходимо.
S>Ну, лично мне это странно слышать. Есть, конечно, "технические" транзакции (типа коммит после каждой записи лога, чтобы обеспечить максимум информации в случае сбоя), но в основном "ноги" у транзакций растут именно из бизнеса. Сам бизнес рассматривается как набор процессов, которые представляют собой цепочки транзакций.
S>При этом в бизнес-транзакцию в отличие от того, что происходит по begin tran, может включаться много всяких ресурсов. Например, транзакция "обработка заказа" может включать в себя, помимо записи чего-то в базу, поиск товара на складе, упаковку его в тару и передачу в транспортную компанию, а также отправку емейла. И всё это должно удовлетворять требованиям ACID. Именно бизнес определяет, не поделить ли этот процесс на другие транзакции — например, для оптимизации выделить передачу в транспортную компанию в отдельную транзакцию.

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

Вот тут:

Re[8]: Оформление работы с БД в корпоративных приложениях -

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Aviator, Вы писали:

A>>Практически к любой ORM можно прикрутить поддержку практически любой БД.
A>Да, може тогда поможете мне прикрутить поддержку диалекта FB к одному из симпатичных мапперов без данной поддержки?

Если ORM поддерживает подобные расширения (нормальная поддерживает), то не вижу проблем в решении этой здачи. Мапер BLT изначально писалься для MSSQL, но потом добавился Оракл, народ с MySql использует, про тот же firebird что-то слышал но не уверен.
По поводу вопроса — вряд ли. Я с Firebird не работал, пользы от меня в такой задаче будет крайне мало.

Здравствуйте, Sinclair, Вы писали:

S>Декларативность языка, говоря неформально — это описание того, что нужно получить, а не как.

Наличие декларативных элементов не делает язык декларативным. А то мы и C# можем обозвать декларативным следуя этой логике.

S>В этом смысле и Пролог, и SQL вполне себе декларативны.

SQL не является декларативным языком программирования потому, что он не является языком программирования ВООБЩЕ.

http://ru.wikipedia.org/wiki/SQL

S>Более того, Пролог тоже является информационно-логическим языком, если говорить о более формальной классификации.

Не понял с чего Вы решили, что Пролог является информационно-логическим языком?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>Так бизнес-транзакции понятие совсем другой категории и не понятно каким боком оно приведено в совокупности с транзакциями базы данных. Человек говорил ХП это хорошо потому, что я могу транзакции в них использовать.

kuj это в народе называется прыгать на словах. Вот тут, несколькими сообщениями выше
http://www.rsdn.ru/forum/message/2669032.1.aspx
ты утверждал что бизнес-транзакций нет. А сейчас вдруг выяснил что они есть, но не тоже самое, что БД-транзакции. Я конечно рад, что ты так быстро умнеешь, но всё же я ценю в людях постоянство.
А началось всё ещё раньше — http://www.rsdn.ru/forum/message/2668397.1.aspx когда ты заявил что транзакции выполняются на сервере (гениально, а мужики-то не знали!) правда забыл уточнить на каком именно.

Здравствуйте, Kazna4ey, Вы писали:

Никогда бы не подумал, что вопрос использования хранимых процедур может вызвать такой прямо-таки шквал полярных мнений.
Правильный ответ: всё зависит от сценария.
Нельзя воспринимать БД отдельно от приложения.

На всякий случай напомню, что хранимые процедуры позволяют (как и многие другие средства) ввести еще один уровень в приложение. С этой точки зрения и нужно их рассматривать.

Сценарий 1. Простое приложение.
Нафига лишний слой? Чтобы было что пописать?
Рассказы про планы запросов и про некомпетентных девелоперов здесь неуместны. Маленькое приложение не пишется командой в 40 человек с разными умениями; планы всех запросов прекрасно построит СУБД, а нужные индексы легко добавить и по результатам опытной эксплуатации.

Сценарий 2. СУБД как сервер приложений
Если потребная приложению бизнес-логика мало выходит за пределы вопросов обработки данных, это неплохой вариант. Перенести характерные сценарии в ХП гораздо лучше, чем гонять их из толстого клиента. Это улучшит и масштабируемость, и поддерживаемость.
Чего стоит бояться — введения ХП на каждый чих. К примеру, поддержку справочников вовсе незачем запихивать в ХП — это всего лишь увеличение объема кода, который нужно править при добавлении еще одной колонки. ХП должны формировать интерфейс сервера приложений. Если есть там какой-то сложный процесс обработки заказа, с поиском распределения по складам и оптимального формирования набора пакетов — так и пишите, create procedure ProcessOrder.
Критерий того, что стоит писать ХП — изменение списка параметров менее вероятно чем изменение логики. Именно поэтому хранимки для CRUD — фигня в 99.9% случаев.

Сценарий 3. Работа с сервером приложений.
Если у вас есть выделенный сервер приложений или слой, играюший его роль, то интерфейсом серверной части заведует именно он. В этом случае введение еще одного слоя в виде ХП в большинстве случаев неоправдано. У вас уже будет метод StoreSystem.ProcessOrder, а как уж он там внутри устроен — его дело. Там может быть использован O/R маппер или прямые SQL запросы. Но опять же, в этом случае использование ХП в большинстве случаев приведет только к увеличению объема кода и дополнительным возможностям по рассогласованию.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, kuj, Вы писали:

S>>Декларативность языка, говоря неформально — это описание того, что нужно получить, а не как.
kuj>Наличие декларативных элементов не делает язык декларативным. А то мы и C# можем обозвать декларативным следуя этой логике.

Фигасе. В SQL оказывается декларативные элементы. Кодд вероятно перевернулся в гробу раза два.

Здравствуйте, kuj, Вы писали:

kuj>Ну может расскажете или хотя бы ссылку на ресурс дадите о тестировании ХП в СУБД?

Visual Studio — пишите любые тесты, какие вам нужно. При поиске в поисковиках думаю сможите найти и что-то специализированое. Или вас интересует теория о том как тестировать ХП в СУБД?

Здравствуйте, adontz, Вы писали:

A>>>Нет, значит ты меня утомил. Не надо искать всемирный заговор там, где его нет. Ты задаёшь глупые вопросы, пересказываешь лозунги, но сам по сути ничего существенного кроме "ОRМ-рулят" не сказал. Все тво комментарии сводятся к "ну-ну" и "вы вообще знаете?". Мне такая дискуссия не интересна, она скучна и утомительна. Я не буду отвечать на твои вопросы не потому что нет ответов, а потому что меня не интересуют твои вопросы.

kuj>>Рекомендую в будущем не ввязываться в спор, если не имеете представления о предмете спора, чтоб не выставлять себя клоуном, как это случилось в этом топике.

A>Хотя, конечно, заявления что SQL не декларативный язык и что бизнес-транзакций не существует ещё надолго запомнятся. Я понимаю, когда люди спорят о чём-то новом и не известном, но когда начинают определять факты данные по определению это просто утомляет.
Спорите о неизвестном здесь только Вы.

Кстати, по поводу языков программирования... надеюсь Вы разобрались с разницей между T-SQL и SQL, а так же знаете теперь, что T-SQL это процедурный язык программирования, что есть синоним императивного программирования? А так же что SQL не является языком программирования?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, ilvi, Вы писали:

kuj>>Ну может расскажете или хотя бы ссылку на ресурс дадите о тестировании ХП в СУБД?

I>Visual Studio — пишите любые тесты, какие вам нужно.
Эээ в VS нету средств для тестирования ХП в БД или я что-то пропустил?

I>При поиске в поисковиках думаю сможите найти и что-то специализированое.
Так может все-таки подскажете?

I>Или вас интересует теория о том как тестировать ХП в СУБД?
Теорию тоже хотелось бы послушать или хотя бы подскажите где об этом можно почитать?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>А так же что SQL не является языком программирования?

В английской версии статьи, которой я доверяю гораздо больше, этого утверждения нет.

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

Здравствуйте, adontz, Вы писали:

kuj>>Так бизнес-транзакции понятие совсем другой категории и не понятно каким боком оно приведено в совокупности с транзакциями базы данных. Человек говорил ХП это хорошо потому, что я могу транзакции в них использовать.

A>kuj это в народе называется прыгать на словах. Вот тут, несколькими сообщениями выше
A>http://www.rsdn.ru/forum/message/2669032.1.aspx
A>ты утверждал что бизнес-транзакций нет. А сейчас вдруг выяснил что они есть, но не тоже самое, что БД-транзакции. Я конечно рад, что ты так быстро умнеешь, но всё же я ценю в людях постоянство.
A>А началось всё ещё раньше — http://www.rsdn.ru/forum/message/2668397.1.aspx когда ты заявил что транзакции выполняются на сервере (гениально, а мужики-то не знали!) правда забыл уточнить на каком именно.

Так, простите, каким боком бизнес-транзакции относятся к БД, к DAL, к хранимым процедурам и к ORM? Или Вы это ляпнули так ... для проформы?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>Так, простите, каким боком бизнес-транзакции относятся к БД, к DAL, к хранимым процедурам и к ORM? Или Вы это ляпнули так ... для проформы?

Бизнес-транзакции очень даже относятся и к DAL, и к ORM, так как иногда надо делать не только commit, но и rollback. Это должно как минимум поддерживаться, не говоря уже об эффективной поддержке. А ещё бывают аппаратные сбои в результате которых тоже надо делать откаты. Например, ты перевёл клиента в статус должника, но если ему не отправился СМС об этом оповещающий, то клиент не переводится. А срок доставки СМСа сутки и за это время сервера могут даже перегрузить.

А теперь подумай над двумя вопросами:
Как эффективно решить эту проблему с помошью кеша второго уровня Hibernate о котором я ничего не знаю?
Причём тут ХП, с которых начался весь разговор?

Здравствуйте, kuj, Вы писали:

I>>Visual Studio — пишите любые тесты, какие вам нужно.
kuj>Эээ в VS нету средств для тестирования ХП в БД или я что-то пропустил?

I>>Или вас интересует теория о том как тестировать ХП в СУБД?
kuj>Теорию тоже хотелось бы послушать или хотя бы подскажите где об этом можно почитать?

Неподскажу

Целенаправленым поиском, о том как тестировать конкретно ХП в СУБД не занимался, не считал что для этого нужно специальные теории читать. Работал точно так же как и с кодом, отлаживал пошагово. Писал сам ручками приложения, которые проверяют корректность работы ХП, причем и знать не знал, что это такая проблемма для общественности.

Просто еще раз попытаюсь высказать свою мысль. Есть люди с разными складами ума, есть различные инструменты для работы, есть различные задачи и цели. Нельзя распространять один подход на всех и вся, даже если он супер-пупер распрекрасный. В коные концов профессионал своего дела не должен быть рабом своего инструмента. В этом плане я полностью поддерживаю Sinclair с его примером (Простое приложение; СУБД как сервер приложений; Работа с сервером приложений).

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Cyberax, Вы писали:
C>>Ага, ты нашел самую гадостную для РБД вещь

A>Она меня сама нашла несколько лет назад. Причём меня тогда поразило то что я не то чтобы не смог с наскоку сделать хоть как-то, а то что я с наскоку вообще ничего не смог сделать. Пришлось задуматся. А потом я начал понимать, что БД и объекты совсем разные вещи и разрабатывать их надо отдельно.
Ну тут если "по книжке" действовать — как раз все в полиморфный mapping и разворачивается.

Другое дело, что его сильно пинать потом надо до рабочего состояния — для этой задачи нет нормальных идеальных решений из-за ограничений самой модели, поэтому приходится идти на компромисы и делать хаки, чтобы оно работало на практических объемах данных

C>>2) Делаем полиморфное отношение с join-таблицами и полем-дискриминатором. Масштабироваться будет достаточно неплохо, но не неограничено.
A>Ну вот что-то типа этого и внедрили в итоге. Мне вообще такие гадостные вещи попадаются достаточно часто. Наверное я неудачник и пока все остальные счастливы на стандартных, легко отображаемых задачах, я ломаю голову над своими плохо отображаемыми

У меня подобные же проблемы — вот тут часть описана http://www.rsdn.ru/Forum/Default.aspx?mid=2629471&flat=0

Только вот после этого всего я стал жутко нелюбить базы данных и все что с ними связано

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kuj, Вы писали:

S>>>Декларативность языка, говоря неформально — это описание того, что нужно получить, а не как.
kuj>>Наличие декларативных элементов не делает язык декларативным. А то мы и C# можем обозвать декларативным следуя этой логике.

A>Фигасе. В SQL оказывается декларативные элементы. Кодд вероятно перевернулся в гробу раза два.

декларативное:
SELECT ...

императивное:
CREATE TABLE, VIEW, INDEX, ...
DROP TABLE, VIEW, INDEX, ...

Так понятнее?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, ilvi, Вы писали:

I>>>Visual Studio — пишите любые тесты, какие вам нужно.
kuj>>Эээ в VS нету средств для тестирования ХП в БД или я что-то пропустил?

I>>>Или вас интересует теория о том как тестировать ХП в СУБД?
kuj>>Теорию тоже хотелось бы послушать или хотя бы подскажите где об этом можно почитать?

I>Неподскажу

Целенаправленым поиском, о том как тестировать конкретно ХП в СУБД не занимался, не считал что для этого нужно специальные теории читать. Работал точно так же как и с кодом, отлаживал пошагово. Писал сам ручками приложения, которые проверяют корректность работы ХП, причем и знать не знал, что это такая проблемма для общественности.

В том и проблема, что тестировать процедуры самописными приложениями полноценно не выйдет. Для тестирования CLR у меня есть средства для мокинга, благодаря которым я могу тестировать конкретно нужный мне метод, а не этот метод И все методы, которые он вызывает, как пример.

IProjectView projectView = mocks.CreateMock<IProjectView>();
Expect.Call(projectView.Title).Return("Project's Title");

Посмотрите, например http://www.ayende.com/projects/rhino-mocks.aspx

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Aviator, Вы писали:
A>Был задан очень хороший и вполне конкретный вопрос. Причём этот вопрос задавался неоднократно по этой теме. Ты сказал что тестируешь ХП и БД. Общественность заинтересовалась как ты это делаешь. У меня вот, например, так и не получилось

, так что я с удовольствием почитаю как.
Ну, вот я лично не тестирую, но знаю, что тестирование приложений с БД вообще значительно затруднено. В принципе. Просто потому, что поведение системы зависит от очень большого и размазанного состояния.

Ну вот как мы тестируем функции? Функция замкнута относительно своих параметров, поэтому достаточно проверить ее на некотором наборе.

Assert(4 == Mul(2, 2));
Assert(0 == Mul(0, 2));
Assert(0 == Mul(2, 0));
Assert(1 == Mul(-1, -1));

Как мы тестируем класс?
Приводим объект в некоторое состояние, выполняем вызовы методов. Приводим в другое состояние, снова выполняем вызовы методов.

Как мы тестируем, к примеру, отчет в корпоративном приложении?
Запускаем на продакшн-базе, сидим с калькулятором в руках.

В теории всё должно работать так же, как и везде:
1. создали тестовую БД
2. наполнили ее тестовыми данными
3. прогнали набор тестовых операций
4. проверили нужные ассерты.
Я не вижу принципиальной разницы в сложности п.3 для ХП и ORM. Вся сложность обвчно в п.2. Если его выполнить, остальное сработает примерно одинаково.
Поэтому сейчас появляются инструменты тестирования data-приложений, которые делают именно так. Например, MS VS for Database Professionals. Там можно тестовые данные генерить, можно снимать образец с production базы. Можно делать нагрузочное тестирование и проверять плазы запросов. И всё это в том числе автоматически и по расписанию.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, adontz, Вы писали:

kuj>>Так, простите, каким боком бизнес-транзакции относятся к БД, к DAL, к хранимым процедурам и к ORM? Или Вы это ляпнули так ... для проформы?

A>Бизнес-транзакции очень даже относятся и к DAL, и к ORM, так как иногда надо делать не только commit, но и rollback. Это должно как минимум поддерживаться, не говоря уже об эффективной поддержке. А ещё бывают аппаратные сбои в результате которых тоже надо делать откаты. Например, ты перевёл клиента в статус должника, но если ему не отправился СМС об этом оповещающий, то клиент не переводится. А срок доставки СМСа сутки и за это время сервера могут даже перегрузить.

A>А теперь подумай над двумя вопросами:
A>Как эффективно решить эту проблему с помошью кеша второго уровня Hibernate о котором я ничего не знаю?

При чем тут кеш второго уровня? oO

И с чего Вы решили, что транзакции БД это единственный способ организации бизнес-транзакций? А так же почему Вы думаете, что я не могу организовать бизнес-транзакцию средствами управления транзакций БД в ОРМ?

Разберитесь сначала в терминологии и не сваливайте все в одну кучу.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>декларативное:
kuj>SELECT ...

kuj>императивное:
kuj>CREATE TABLE, VIEW, INDEX, ...
kuj>DROP TABLE, VIEW, INDEX, ...
kuj>Так понятнее?

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

Даже если на 5 минут сойти с ума и предположить что ты прав, это всё равно не корректный способ сравнения — считать ключевые слова относящиеся к той или иной обласни. SELECT пишется гораздо гаще, на порядки чаще, чем CREATE, а исполняется в миллиарды раз чаще.

Здравствуйте, kuj, Вы писали:

kuj>В том и проблема, что тестировать процедуры самописными приложениями полноценно не выйдет. Для тестирования CLR у меня есть средства для мокинга, благодаря которым я могу тестировать конкретно нужный мне метод, а не этот метод И все методы, которые он вызывает, как пример.

Ты видимо не очень это понимаешь, но SQL и обсуждемые расширения с диалектами не являются ОО, а значит мок-объекты им не светят. По определению.
Кроме того, если мы говорим о тестировании, БД не являются сущностями, которые можно протестировать полностью. По той же причине, что и многопоточные приложения, например.

Здравствуйте, kuj, Вы писали:

kuj>При чем тут кеш второго уровня? oO

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

kuj>И с чего Вы решили, что транзакции БД это единственный способ организации бизнес-транзакций?

Во-первых, я этого не говорил.
Во-вторых, утвержнение не верное. Транзакции БД это не просто не единственный способ, это не способ вовсе.

kuj>Разберитесь сначала в терминологии и не сваливайте все в одну кучу.

Взаимно.

Здравствуйте, Sinclair, Вы писали:

S>В теории всё должно работать так же, как и везде:
S>1. создали тестовую БД
S>2. наполнили ее тестовыми данными
S>3. прогнали набор тестовых операций
S>4. проверили нужные ассерты.
S>Я не вижу принципиальной разницы в сложности п.3 для ХП и ORM. Вся сложность обвчно в п.2. Если его выполнить, остальное сработает примерно одинаково.
Да, а как вы в процедурах делаете mocking? Или у вас все процедуры без зависимостей от других процедур и зависят исключительно от данных в БД?

Проблема с тестированием того же в DAL в ORM связанна непосредственно с БД. Тесты сами по себе могут менять состояние БД. Тестов много и они должны отрабатывать быстро и при этом БД нужно возвращать в исходное состояние каждый раз. Для больших проектов прогонка полного комплекта тестов на DAL может занимать часы, что мягко говоря не способствует их частой прогонке.

S>Поэтому сейчас появляются инструменты тестирования data-приложений, которые делают именно так. Например, MS VS for Database Professionals. Там можно тестовые данные генерить, можно снимать образец с production базы. Можно делать нагрузочное тестирование и проверять плазы запросов. И всё это в том числе автоматически и по расписанию.

Вот это уже интересно и по делу. Будем почитать.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>Даже если на 5 минут сойти с ума и предположить что ты прав, это всё равно не корректный способ сравнения — считать ключевые слова относящиеся к той или иной обласни. SELECT пишется гораздо гаще, на порядки чаще, чем CREATE, а исполняется в миллиарды раз чаще.
Не спорьте, вы оба правы

Классический ANSI SQL — это декларативный язык.

T-SQL и PL/SQL кроме декларативного SQL еще поддерживают и императивные конструкции (циклы, сравнения, ветвления, присваивания).

Здравствуйте, adontz, Вы писали:

kuj>>При чем тут кеш второго уровня? oO

A>Я не знаю, это твой вечный аргумент. Чтобы я не сказал, ыт мне тычешь под нос кешем второго уровня.

Ну так разберитесь сначала с тем, что есть кеш второго уровня в Hibernate и зачем он нужен. К транзакциям же он никакого отношения не имеет.

kuj>>И с чего Вы решили, что транзакции БД это единственный способ организации бизнес-транзакций?

A>Во-первых, я этого не говорил.
A>Во-вторых, утвержнение не верное. Транзакции БД это не просто не единственный способ, это не способ вовсе.

Рад, что Вы наконец хоть с этим разобрались.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>декларативное:
kuj>>SELECT ...

kuj>>императивное:
kuj>>CREATE TABLE, VIEW, INDEX, ...
kuj>>DROP TABLE, VIEW, INDEX, ...
kuj>>Так понятнее?

A>Так не понятнее, потому что глупость. DDL не является императивной частью, он точно такая же декларативная часть. Ты указываешь конечный результат — таблицу, а не пришешь генерацию внутреней структуры файлов: записей, индексов.

О да, по Вашей логике получается, что

MessageBox m = new MessageBox()
Это тоже декларативная конструкция, т.к. я "указываю на конечный результат" — MessageBox. Верно?

Почитайте определение императивного языка. Может поймете все же... А еще лучше изучите Prolog.

A>Даже если на 5 минут сойти с ума и предположить что ты прав, это всё равно не корректный способ сравнения — считать ключевые слова относящиеся к той или иной обласни. SELECT пишется гораздо гаще, на порядки чаще, чем CREATE, а исполняется в миллиарды раз чаще.

Хорошо, тогда ответьте мне, а HTML тоже является декларативным языком программирования?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:
S>>Я не вижу принципиальной разницы в сложности п.3 для ХП и ORM. Вся сложность обвчно в п.2. Если его выполнить, остальное сработает примерно одинаково.
kuj>Да, а как вы в процедурах делаете mocking? Или у вас все процедуры без зависимостей от других процедур и зависят исключительно от данных в БД?
Ну, вообще-то мокинг процедур, имхо, сделать вообще нереально. В том-то и дело, что в отличие от хорошо структурированных программ, базы данных имеют дело с shared state. Собственно, одна хранимка потребляет результаты другой исключительно в виде произведенных ею изменений в разделяемых данных. Я имею в виду ХП в смысле MS SQL Server. То, что в IB/FB делается через suspend я предпочитаю называть table-valued функциями, и я вовсе не уверен, что их вообще имеет смысл подменять моками при тестировании. Речь идет о том, что мы тестируем не отдельную хранимку, а поведение всей системы. И по-другому нельзя. По хорошему это именно так: подняли сервер, наколотили в него тестовых данных, выполнили набор SOAP вызовов.
С юнит-тестами тут тяжко, я вообще не очень понимаю, как можно что-то в базе заюниттестить. Не изолируется потому что нифига.

kuj>Проблема с тестированием того же в DAL в ORM связанна непосредственно с БД. Тесты сами по себе могут менять состояние БД. Тестов много и они должны отрабатывать быстро и при этом БД нужно возвращать в исходное состояние каждый раз. Для больших проектов прогонка полного комплекта тестов на DAL может занимать часы, что мягко говоря не способствует их частой прогонке.
Вообще говоря, прогон тестов раз в сутки — вполне достаточно. По сравнению с ручным тестированием, один цикл которого у нас занимает примерно три недели, это недостижимая мечта.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, adontz, Вы писали:

kuj>>В том и проблема, что тестировать процедуры самописными приложениями полноценно не выйдет. Для тестирования CLR у меня есть средства для мокинга, благодаря которым я могу тестировать конкретно нужный мне метод, а не этот метод И все методы, которые он вызывает, как пример.

A>Ты видимо не очень это понимаешь, но SQL и обсуждемые расширения с диалектами не являются ОО, а значит мок-объекты им не светят. По определению.
A>Кроме того, если мы говорим о тестировании, БД не являются сущностями, которые можно протестировать полностью. По той же причине, что и многопоточные приложения, например.

Рад, что вы хоть в чем-то разобрались со вчерашнего дня. Данный спор идет Вам на пользу:

"Кроме того, использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными. Это особенно актуально при изменении схемы (добавлении столбца, а то и таблицы). "

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>MessageBox m = new MessageBox()
kuj>Это тоже декларативная конструкция, т.к. я "указываю на конечный результат" — MessageBox. Верно?

Нет. Тут явный вызов функции.

kuj>Хорошо, тогда ответьте мне, а HTML тоже является декларативным языком программирования?

Декларативный — да, язык программирования — нет. HTML определяет статическую структуру документа (вместе с CSS — конечный автомат), а не какие-либо действия.

Здравствуйте, kuj, Вы писали:

A>>Во-первых, я этого не говорил.
A>>Во-вторых, утвержнение не верное. Транзакции БД это не просто не единственный способ, это не способ вовсе.
kuj>Рад, что Вы наконец хоть с этим разобрались.

Я? Это ты разобрался. 12 часов назад ты утверждал что бизнес-транзакций вовсе нет!

Здравствуйте, kuj, Вы писали:

A>>Кроме того, если мы говорим о тестировании, БД не являются сущностями, которые можно протестировать полностью. По той же причине, что и многопоточные приложения, например.
kuj>Рад, что вы хоть в чем-то разобрались со вчерашнего дня. Данный спор идет Вам на пользу:
kuj>"Кроме того, использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными. Это особенно актуально при изменении схемы (добавлении столбца, а то и таблицы). "

Ты всё вечно читаешь не так как написано, а так хочется твоему эго. Не полностью тестируемые не означает не тестируемые вовсе.

Здравствуйте, Sinclair, Вы писали:

S>>>Я не вижу принципиальной разницы в сложности п.3 для ХП и ORM. Вся сложность обвчно в п.2. Если его выполнить, остальное сработает примерно одинаково.
kuj>>Да, а как вы в процедурах делаете mocking? Или у вас все процедуры без зависимостей от других процедур и зависят исключительно от данных в БД?
S>Ну, вообще-то мокинг процедур, имхо, сделать вообще нереально. В том-то и дело, что в отличие от хорошо структурированных программ, базы данных имеют дело с shared state. Собственно, одна хранимка потребляет результаты другой исключительно в виде произведенных ею изменений в разделяемых данных. Я имею в виду ХП в смысле MS SQL Server. То, что в IB/FB делается через suspend я предпочитаю называть table-valued функциями, и я вовсе не уверен, что их вообще имеет смысл подменять моками при тестировании. Речь идет о том, что мы тестируем не отдельную хранимку, а поведение всей системы. И по-другому нельзя. По хорошему это именно так: подняли сервер, наколотили в него тестовых данных, выполнили набор SOAP вызовов.
S>С юнит-тестами тут тяжко, я вообще не очень понимаю, как можно что-то в базе заюниттестить. Не изолируется потому что нифига.

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

kuj>>Проблема с тестированием того же в DAL в ORM связанна непосредственно с БД. Тесты сами по себе могут менять состояние БД. Тестов много и они должны отрабатывать быстро и при этом БД нужно возвращать в исходное состояние каждый раз. Для больших проектов прогонка полного комплекта тестов на DAL может занимать часы, что мягко говоря не способствует их частой прогонке.
S>Вообще говоря, прогон тестов раз в сутки — вполне достаточно. По сравнению с ручным тестированием, один цикл которого у нас занимает примерно три недели, это недостижимая мечта.

В том то и дело, что прогон раз в сутки часто не достаточно. В идеале тесты должны прогоняться после малейшего изменения. Потому и необходимо столь жесткое разделение на слои и домены: хранилище — DAL — BLL — ...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Кроме того, если мы говорим о тестировании, БД не являются сущностями, которые можно протестировать полностью. По той же причине, что и многопоточные приложения, например.
kuj>>Рад, что вы хоть в чем-то разобрались со вчерашнего дня. Данный спор идет Вам на пользу:

kuj>>"Кроме того, использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными. Это особенно актуально при изменении схемы (добавлении столбца, а то и таблицы). "

A>Ты всё вечно читаешь не так как написано, а так хочется твоему эго. Не полностью тестируемые не означает не тестируемые вовсе.

То есть ХП уже не тестируемые вовсе? Как полярно у Вас поменялось мнение... Надо же.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>MessageBox m = new MessageBox()
kuj>>Это тоже декларативная конструкция, т.к. я "указываю на конечный результат" — MessageBox. Верно?

A>Нет. Тут явный вызов функции.

Где там явный вызов функции и чем это отличается от CREATE TABLE?

CREATE TABLE ...
CREATE INDEX ...
CREATE VIEW ...

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

При декларативном программировании нет никаких последовательностей действий, потому и порядок не имеет роли.

Декларативное программирование, это например

  predicates
      term (real, string)
  clauses
      term (T, "Лёд"):- T<=0.
        term (T, "Жидкость"):- T>0, T<=100.
      term (T, "Пар"):- T>100.

Так понятно?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:
A>Если бы T-SQL был чисто императивным процедурным языком, то тебе вместо декларативного описания результата запроса пришлось бы императивно определять план его исполнения. Этого не наблюдается.
Да-да. Неверящим в императивные языки программирования СУБД рекомендую ознакомиться c dBase/Clipper и посмотреть, как выполнялись всякие джойны и прочее в до-SQL эпоху.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, kuj, Вы писали:
kuj>В том то и дело, что прогон раз в сутки часто не достаточно. В идеале тесты должны прогоняться после малейшего изменения. Потому и необходимо столь жесткое разделение на слои и домены: хранилище — DAL — BLL — ...
На доступном мне уровне развития науки, сие для БД-ориентированных приложений решительно невозможно. Даже не-БД тестировать "после малейшего изменения" нереально, т.к. банальная сборка мало-мальски сложного проекта начинает занимать больше времени, чем проходит между коммитами в SVN.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, adontz, Вы писали:

A>>>Во-первых, я этого не говорил.
A>>>Во-вторых, утвержнение не верное. Транзакции БД это не просто не единственный способ, это не способ вовсе.
kuj>>Рад, что Вы наконец хоть с этим разобрались.

A>Я? Это ты разобрался. 12 часов назад ты утверждал что бизнес-транзакций вовсе нет!
Не перекручивайте слова.

Напоминаю ход разговора:

----------
http://rsdn.ru/Forum/Message.aspx?mid=2668296&only=1

A>>Если транзакция нужна, а её нет ORM не спасёт.
kuj>Какие проблемы с транзакциями? OR/M отлично справляются с организацией транзакций.
БД справляется ещё лучше. Нельзя на ORM сваливать всё то, что лень было запрограммировать в БД, так как в результате ты получишь неповоротливую систему.
----------

----------
A>>>ОМГ. У тебя есть две машины, на одной всё что на java, на воторой SQL-сервер. Это достаточно стандартная схема.
C>>У меня вот два сервера БД (кластер с failover) и 3 app-сервера в качестве front-end'ов. Все прекрасно работает с Hibernate.

A>Почетай выше о чём вообще речь, kuj совсем не понимает чем транзакции уровня БД отличаются от транзакций уровня бизнес-логики.

Транзакции уровня бизнес-логики? Вот это круто. Вы это только что придумали?
----------

На что Вы в дальнейшем сказали:

----------
kuj>И с чего Вы решили, что транзакции БД это единственный способ организации бизнес-транзакций?

Во-первых, я этого не говорил.
Во-вторых, утвержнение не верное. Транзакции БД это не просто не единственный способ, это не способ вовсе.
----------

Мухи отдельно, котлеты отдельно, да?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Sinclair, Вы писали:

kuj>>В том то и дело, что прогон раз в сутки часто не достаточно. В идеале тесты должны прогоняться после малейшего изменения. Потому и необходимо столь жесткое разделение на слои и домены: хранилище — DAL — BLL — ...
S>На доступном мне уровне развития науки, сие для БД-ориентированных приложений решительно невозможно. Даже не-БД тестировать "после малейшего изменения" нереально, т.к. банальная сборка мало-мальски сложного проекта начинает занимать больше времени, чем проходит между коммитами в SVN.

А почему Вы решили, что нужно собирать весь проект?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Доброе утро/день!

11 страниц назад я попросил:

ОЧЕНЬ хотелось бы попросить, чтобы вы привели примеры кода, с разных уровней, т.е. как выглядит код в уровне GUI (в обработчиках кнопок например), этот код будет взаимодействовать с объектами из следующего уровня — приведите код из следующего уровня и т.д. Т.е. чтобы можно было кратко представить целую картину по оформлению работы с БД в приложении. А то сейчас все довольно абстрагировано, по крайней мере для меня — человека НЕ С ВАШИМ уровнем и опытом.
Это относится к обоим выделившимся сторонам обсуждения (Adontz и все остальные .

Вы конечно ничего никому не обязаны объяснять, но вот вам не жалко тратить ЧАСЫ на ведение этого спора, а несколько минут потратить чтобы вернуться к теме привести примеры — жалко?

Заранее спасибо...

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, adontz, Вы писали:
A>>Если бы T-SQL был чисто императивным процедурным языком, то тебе вместо декларативного описания результата запроса пришлось бы императивно определять план его исполнения. Этого не наблюдается.
S>Да-да. Неверящим в императивные языки программирования СУБД рекомендую ознакомиться c dBase/Clipper и посмотреть, как выполнялись всякие джойны и прочее в до-SQL эпоху.
Ну работал я с таким АПИ без sql со старой СУБД. Но это никак не означает, что t-sql декалартивный язык

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, adontz, Вы писали:

A>>Даже если на 5 минут сойти с ума и предположить что ты прав, это всё равно не корректный способ сравнения — считать ключевые слова относящиеся к той или иной обласни. SELECT пишется гораздо гаще, на порядки чаще, чем CREATE, а исполняется в миллиарды раз чаще.
C>Не спорьте, вы оба правы

Классический ANSI SQL — это декларативный язык.

C>T-SQL и PL/SQL кроме декларативного SQL еще поддерживают и императивные конструкции (циклы, сравнения, ветвления, присваивания).
Только проблема в том, что в хранимках плотность императивных конструкций максимальна

Здравствуйте, adontz, Вы писали:
A>Ты всё вечно читаешь не так как написано, а так хочется твоему эго. Не полностью тестируемые не означает не тестируемые вовсе.

Зашибись, наконецтаки ты признал то что уже всем очевидно — нифига ты не тестируешь логику. А все тесты наверняка сводятся к проигрыванию пары сценариев на подготовленной базе, если не вообще к нажатию кнопарей на форме клиентского приложения. Так вот, это называется функциональным тестированием, которое выполняют тестёры. А программист занимается глубоким тестированием кода, создавая юнит тесты для того что бы проверить, что ожидаемое поведение кажлдого малейшего куска системы совпадает с реальным. Без такого тестирования функциональное тестирование малоэффективно. А у вас в роли тестёров выступает конечный пользователь видимо

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>Ну это прям лозунг для баррикад. И что же за такие проекты, для которых применения маппера оборачивается мучением?

TDD это не технология, это образ мышления.

A>Есть не тестируемые задачи, как же ты бедненький о них думаешь? Технологии служат разработчику, а не наоборот, не забыл?
Не тестируемые это как? Объяснение с примером в стулию

. У вас что, поведение кода непредсказуемое? Ну тогда тут вообще нечего обсуждать

Здравствуйте, Sinclair, Вы писали:

S>Поэтому сейчас появляются инструменты тестирования data-приложений, которые делают именно так. Например, MS VS for Database Professionals. Там можно тестовые данные генерить, можно снимать образец с production базы. Можно делать нагрузочное тестирование и проверять плазы запросов. И всё это в том числе автоматически и по расписанию.

Наконец хороший ответ, от adontz этого не дождёшься видимо

. Но согласитесь, что это всё-таки ближе к функциональному тестированию, чем к юнит тестам?

Здравствуйте, Aviator, Вы писали:
A>Ну работал я с таким АПИ без sql со старой СУБД. Но это никак не означает, что t-sql декалартивный язык

.
T-SQL — это, естественно, мультипарадигменный язык.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Aviator, Вы писали:
A>Наконец хороший ответ, от adontz этого не дождёшься видимо

. Но согласитесь, что это всё-таки ближе к функциональному тестированию, чем к юнит тестам?
Да-да, я так и написал. Я вообще затрудняюсь насчет юнит-тестирования чего-то с участием БД.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Да-да. Неверящим в императивные языки программирования СУБД рекомендую ознакомиться c dBase/Clipper и посмотреть, как выполнялись всякие джойны и прочее в до-SQL эпоху.

Покажете?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Нахлобуч, Вы писали:
Н>Покажете?
Увы, мой код 1992 года потерян за давностью лет.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Kazna4ey, Вы писали:

K>Доброе утро/день!

K>11 страниц назад я попросил:
K>

ОЧЕНЬ хотелось бы попросить, чтобы вы привели примеры кода, с разных уровней, т.е. как выглядит код в уровне GUI (в обработчиках кнопок например), этот код будет взаимодействовать с объектами из следующего уровня — приведите код из следующего уровня и т.д. Т.е. чтобы можно было кратко представить целую картину по оформлению работы с БД в приложении. А то сейчас все довольно абстрагировано, по крайней мере для меня — человека НЕ С ВАШИМ уровнем и опытом.
K>Это относится к обоим выделившимся сторонам обсуждения (Adontz и все остальные .

K>Вы конечно ничего никому не обязаны объяснять, но вот вам не жалко тратить ЧАСЫ на ведение этого спора, а несколько минут потратить чтобы вернуться к теме привести примеры — жалко?

K>Заранее спасибо...
смотрел это?

Здравствуйте всем.
Объясните мне, если мы говорим о действительно корпоративных приложениях, как Server Application, обработает данные быстре чем чем БД, которая обычно размещается на отдельном серваке и количество процов как минимум раза в 4-е больше.

Здравствуйте, Aviator, Вы писали:

A>смотрел это?

Да, смотрел, спасибо большое. Но хотелось бы примеры кода (желательно не по 2 строчки) со всех слоев, чтобы увидеть цепочку и понять общую логику, вот например в своем вопросе я привел примеры и думаю абсолютно всем понятно как я строю свое приложение. Вот и мне (и думаю не только мне) хотелось быть понять как вы строите свои приложения (и увидеть это на примерах а не абстрактных выражениях). Большинство из вас работает в командах, вы можете учиться друг у друга, а человеку который работает удаленно или выполняет проект один может быть достаточно проблематично узнать, "а как же делают там"? Я думаю что в принципе я задал вполне конкретный вопрос, — показать примеры с разных слоев, чтобы можно было понять как вы строите свои приложения. Надеюсь кто-то отвлекется от спора и уделит несколько минут на это.

Спасибо.

Здравствуйте, Kazna4ey, Вы писали:

A>>смотрел это?

K>Да, смотрел, спасибо большое. Но хотелось бы примеры кода (желательно не по 2 строчки) со всех слоев, чтобы увидеть цепочку и понять общую логику, вот например в своем вопросе я привел примеры и думаю абсолютно всем понятно как я строю свое приложение. Вот и мне (и думаю не только мне) хотелось быть понять как вы строите свои приложения (и увидеть это на примерах а не абстрактных выражениях). Большинство из вас работает в командах, вы можете учиться друг у друга, а человеку который работает удаленно или выполняет проект один может быть достаточно проблематично узнать, "а как же делают там"? Я думаю что в принципе я задал вполне конкретный вопрос, — показать примеры с разных слоев, чтобы можно было понять как вы строите свои приложения. Надеюсь кто-то отвлекется от спора и уделит несколько минут на это.

K>Спасибо.

Отличные примеры кода в той статье, ссылку на которую я давал ранее. На CodeProject в смысле.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Kazna4ey, Вы писали:

K>Здравствуйте, Aviator, Вы писали:

A>>смотрел это?

K>Да, смотрел, спасибо большое. Но хотелось бы примеры кода (желательно не по 2 строчки) со всех слоев, чтобы увидеть цепочку и понять общую логику, вот например в своем вопросе я привел примеры и думаю абсолютно всем понятно как я строю свое приложение. Вот и мне (и думаю не только мне) хотелось быть понять как вы строите свои приложения (и увидеть это на примерах а не абстрактных выражениях). Большинство из вас работает в командах, вы можете учиться друг у друга, а человеку который работает удаленно или выполняет проект один может быть достаточно проблематично узнать, "а как же делают там"? Я думаю что в принципе я задал вполне конкретный вопрос, — показать примеры с разных слоев, чтобы можно было понять как вы строите свои приложения. Надеюсь кто-то отвлекется от спора и уделит несколько минут на это.
K>Спасибо.

Посмотрите здесь — показан простой и полный сценарий использования. Если что непонятно, задавайте вопросы.

Здравствуйте, Kazna4ey, Вы писали:

K>Здравствуйте, Aviator, Вы писали:

A>>смотрел это?

K>Большинство из вас работает в командах, вы можете учиться друг у друга, а человеку который работает удаленно или выполняет проект один может быть достаточно проблематично узнать, "а как же делают там"?

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

Здравствуйте, stenkil, Вы писали:

S>Здравствуйте всем.
S>Объясните мне, если мы говорим о действительно корпоративных приложениях, как Server Application, обработает данные быстре чем чем БД, которая обычно размещается на отдельном серваке и количество процов как минимум раза в 4-е больше.
Откуда дровишки? Ты и впрямь думаешь, что апп серверу недодадут процов? Не смеши меня.
К тому ж, СУБД крайне редко упирается в CPU. Смотреть на full disclosure reportы про tpc-c, особенно про дисковую подсистему. Фигеть тихо либо громко — на свое усмотрение.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, kuj, Вы писали:

kuj>Все верно. Потому я и считаю, что в случае корпоративных приложений БД следует использовать исключительно как хранилище информации — без хранимых процедур и триггеров.

Вот это и называется фанатично верить в технологию. Есть КУЧА задач, где юнит-тестирование в частности и тестирование вообще не возможно и разглядывание кода (если повезёт, логов) единственный метод отладки. И несмотря ни на что эти задачи успешно решаются.

kuj>В том то и дело, что прогон раз в сутки часто не достаточно. В идеале тесты должны прогоняться после малейшего изменения. Потому и необходимо столь жесткое разделение на слои и домены: хранилище — DAL — BLL — ...

Идеалист-маньяк

Тест после каждого коммита в крупном проекте требует огромной по вычислительной мощности инфраструктуры компиляции и тестрирования.

Здравствуйте, kuj, Вы писали:

kuj>То есть ХП уже не тестируемые вовсе? Как полярно у Вас поменялось мнение... Надо же.

То есть научись читать по-русски. Для тебя предложенияе с двумя запятыми уже проблема.

Здравствуйте, kuj, Вы писали:

kuj>Где там явный вызов функции и чем это отличается от CREATE TABLE?

Явный вызов там MessageBox.__ctor.
От CreateTable это отличается тем, что ты декларируешь результат — таблицу, но не знаешь как она будет создана, каки функции будут вызваны и будут ли вызваны вообще. Может реальное создание таблицы будет отложено до первого CRUD.

Здравствуйте, Aviator, Вы писали:

A>Зашибись, наконецтаки ты признал

А когда я отрицал? читать учитесь.

A>нифига ты не тестируешь логику. А все тесты наверняка сводятся к проигрыванию пары сценариев на подготовленной базе

Сценариев не пара. Логика тестируется. Телепатию в сад.

Здравствуйте, Aviator, Вы писали:

A>Не тестируемые это как? Объяснение с примером в стулию

. У вас что, поведение кода непредсказуемое? Ну тогда тут вообще нечего обсуждать

.

Не тестируемые, значит что ты НЕ можешь автоматически проверить корректность кода.

Код, который с помошью OpenGL визуализирует карту страны и траекторию движения автомобилей на ней. Ты должен просто сесть и помотреть "то" на экране нарисовано или "не то".
Как ты в юнит-тесте проверишь благозвучность синтезированной речи?
Нельзя проверить, что HTML правильно отображается на экране, надо просто открыть и посмотреть.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>Не тестируемые это как? Объяснение с примером в стулию

. У вас что, поведение кода непредсказуемое? Ну тогда тут вообще нечего обсуждать

.

A>Не тестируемые, значит что ты НЕ можешь автоматически проверить корректность кода.

A>Код, который с помошью OpenGL визуализирует карту страны и траекторию движения автомобилей на ней. Ты должен просто сесть и помотреть "то" на экране нарисовано или "не то".
A>Как ты в юнит-тесте проверишь благозвучность синтезированной речи?
A>Нельзя проверить, что HTML правильно отображается на экране, надо просто открыть и посмотреть.

И опять ты ничего не понял

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

Здравствуйте, Aviator, Вы писали:

A>И опять ты ничего не понял

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

. Оно действительно необходимо, но сначала небольшие куски кода проверяются с помощью юнит тестов. Юнит тесты проверяют соответсвие ожидаемого поведения классов и методов с фактическим. Функциональное тестирование проверяет соответсвие предоставляемой приложением функциональности требованиям ТЗ. Это две разные разницы и совершенно различные сферы ответственности. Даже люди вовлечены разные.

Да нет это ты не понял. Разница в том, что люди вовслечены. Для перечисленных задач требует ручное тестирование. Можно и ручное юнит-тестрирование устроить, принципиальной проблемы нет. Важно тут то, что автоматизировать этот процесс не представляется возможным.

Здравствуйте, kuj, Вы писали:

kuj>Мда... я не завидую вашим разработчикам БД, но еще больше я не завидую вашим разработчикам BLL...

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

Здравствуйте, adontz, Вы писали:

C>>Ты знаешь, если мне это нужно будет — я точно так же сделаю два класса User и UserDetails. А если у нас только два поля FirstName/LastName — пусть себе живут в одной таблице.

A>Это надо делать не когда нужно, а на всякий случай. Именно это и отличает хорошего специальста, что он разрабатывает продукт не только для сегодняшнего дня, а с учётом возможных расширений.

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

... << RSDN@Home 1.2.0 alpha rev. 771>>

Здравствуйте, IT, Вы писали:

A>>Это надо делать не когда нужно, а на всякий случай. Именно это и отличает хорошего специальста, что он разрабатывает продукт не только для сегодняшнего дня, а с учётом возможных расширений.

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

Я имел ввиду не добавлять функциональность, а оставлять возможность безболезненного добавления функциональности.

Здравствуйте, Светлояр, Вы писали:

kuj>>Мда... я не завидую вашим разработчикам БД, но еще больше я не завидую вашим разработчикам BLL...

С>adontz прав, приложение должно разрабатываться по информационной структуре,

С чего Вы взяли, что БД это информационная структура приложения? БД это самый нижний уровень для хранения информации. Вот и все и нечего тут выдумывать.

С>Вы должны прекрасно понимать, что приложение лишь интерфейс для управления информацией.

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

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>Где там явный вызов функции и чем это отличается от CREATE TABLE?

A>Явный вызов там MessageBox.__ctor.
Точно так же, как и CREATE TABLE явно императивный оператор означающий: создай мне таблицу с такой-то структурой. Точно так же как и MyObject.CreateAnotherObject(AnotherObjectParams p);

Разница только в синтаксисе.

A>От CreateTable это отличается тем, что ты декларируешь результат — таблицу, но не знаешь как она будет создана, каки функции будут вызваны и будут ли вызваны вообще.
А Вы знаете какие функции будут вызваны в конструкторе MessageBox? Честно-честно?

Короче, Вы НЕ знаете что такое декларативное программирование. Если Вы считаете CREATE TABLE декларативным программированием, то вопросов больше нет. Пробелы в Вашем образовании я восполнять не собираюсь.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>Да нет это ты не понял. Разница в том, что люди вовслечены. Для перечисленных задач требует ручное тестирование. Можно и ручное юнит-тестрирование устроить, принципиальной проблемы нет. Важно тут то, что автоматизировать этот процесс не представляется возможным.

В юмор однозначно. Про "ручное юнит тестирование" это твоё изобретение?

Здравствуйте, kuj, Вы писали:

kuj>А Вы знаете какие функции будут вызваны в конструкторе MessageBox? Честно-честно?
Как минимум будет вызван сам конструктор.

Здравствуйте, adontz, Вы писали:

kuj>>То есть ХП уже не тестируемые вовсе? Как полярно у Вас поменялось мнение... Надо же.

A>То есть научись читать по-русски. Для тебя предложенияе с двумя запятыми уже проблема.

Вы сперва определитесь можно ли тестировать ХП или нет. "Не не полностью" это не русский язык. Это называется двойное отрицание.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Aviator, Вы писали:

A>>Да нет это ты не понял. Разница в том, что люди вовслечены. Для перечисленных задач требует ручное тестирование. Можно и ручное юнит-тестрирование устроить, принципиальной проблемы нет. Важно тут то, что автоматизировать этот процесс не представляется возможным.

A>В юмор однозначно. Про "ручное юнит тестирование" это твоё изобретение?

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

Здравствуйте, adontz, Вы писали:

A>>нифига ты не тестируешь логику. А все тесты наверняка сводятся к проигрыванию пары сценариев на подготовленной базе

A>Сценариев не пара. Логика тестируется. Телепатию в сад.

Ну так расскажите нам КАК Вы тестируете логику? Мы не телепаты — понять Вас без слов не можем.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Aviator, Вы писали:

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

.

кстати, Kazna4ey, вы читали?:

М. Фаулер: Архитектура корпоративных программных приложений

Э. Гамма, Р. Хелм, Р. Джонсон: Приемы объектно-ориентированного проектирования. Паттерны проектирования

М. Фаулер: Рефакторинг. Улучшение существующего кода

С. Макконнелл: Совершенный код

все можно найти в электроннм виде нарусском

Здравствуйте, kuj, Вы писали:

kuj>Вы сперва определитесь можно ли тестировать ХП или нет.

Можно, но не всегда. Как правило — можно.

Здравствуйте, adontz, Вы писали:

A>>Не тестируемые это как? Объяснение с примером в стулию

. У вас что, поведение кода непредсказуемое? Ну тогда тут вообще нечего обсуждать

.

A>Не тестируемые, значит что ты НЕ можешь автоматически проверить корректность кода.

Если Вы не можете проверить корректность кода, значит Вы просто неправильно этот код написали. Вот и все.

A>Код, который с помошью OpenGL визуализирует карту страны и траекторию движения автомобилей на ней. Ты должен просто сесть и помотреть "то" на экране нарисовано или "не то".
Ндааааааа....

Это сильно...

A>Как ты в юнит-тесте проверишь благозвучность синтезированной речи?
Кто Вам сказал, что юнит-тесты должны проверять благозвучность речи? Вы так и не разобрались что такое юнит-тесты... Это как в анекдоте про чукчу-писателя.

A>Нельзя проверить, что HTML правильно отображается на экране, надо просто открыть и посмотреть.
5 баллов...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>Ну так расскажите нам КАК Вы тестируете логику? Мы не телепаты — понять Вас без слов не можем.

Создаётся некоторая предопределённая база (схема+данные). Натравляется ХП. Проверяется, что данные после исполнения ХП соответствуют ожидаемым. Я не думал, что такие вещи надо объяснять.

Здравствуйте, adontz, Вы писали:

A>>И опять ты ничего не понял

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

. Оно действительно необходимо, но сначала небольшие куски кода проверяются с помощью юнит тестов. Юнит тесты проверяют соответсвие ожидаемого поведения классов и методов с фактическим. Функциональное тестирование проверяет соответсвие предоставляемой приложением функциональности требованиям ТЗ. Это две разные разницы и совершенно различные сферы ответственности. Даже люди вовлечены разные.

A>Да нет это ты не понял. Разница в том, что люди вовслечены. Для перечисленных задач требует ручное тестирование. Можно и ручное юнит-тестрирование устроить, принципиальной проблемы нет. Важно тут то, что автоматизировать этот процесс не представляется возможным.

Ручное юнит тестирование.

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

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

A>>Не тестируемые, значит что ты НЕ можешь автоматически проверить корректность кода.
kuj>Если Вы не можете проверить корректность кода

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

A>>Код, который с помошью OpenGL визуализирует карту страны и траекторию движения автомобилей на ней. Ты должен просто сесть и помотреть "то" на экране нарисовано или "не то".
kuj>Ндааааааа....

Это сильно...

Ещё бы, ты ведь дальше своего носа ничего не видел, всё новое тебя удивляет.

kuj>Кто Вам сказал, что юнит-тесты должны проверять благозвучность речи?

А где я тут сказал юнит-тесты? Я тут о тестрировании вообще. Ты как всегда что-то не в тему ляпнул.

Здравствуйте, adontz, Вы писали:

kuj>>Все верно. Потому я и считаю, что в случае корпоративных приложений БД следует использовать исключительно как хранилище информации — без хранимых процедур и триггеров.

A>Вот это и называется фанатично верить в технологию.

Это называется знать реалии жизни.

A>Есть КУЧА задач, где юнит-тестирование в частности и тестирование вообще не возможно и разглядывание кода (если повезёт, логов) единственный метод отладки. И несмотря ни на что эти задачи успешно решаются.

Нету никакой кучи задач. Юнит-тесты это не что-то из ряда фантастики, а вполне конкретная методология автоматического тестирования кода, которой вот уже много-много лет. Вы о ней НИЧЕГО не знаете, но продолжаете спорить, выставляя себя дураком.

Разберитесь сначала, изучите, а потом спорьте.

kuj>>В том то и дело, что прогон раз в сутки часто не достаточно. В идеале тесты должны прогоняться после малейшего изменения. Потому и необходимо столь жесткое разделение на слои и домены: хранилище — DAL — BLL — ...

A>Идеалист-маньяк

Тест после каждого коммита в крупном проекте требует огромной по вычислительной мощности инфраструктуры компиляции и тестрирования.

Ну так идете и разберитесь с юнит-тестированием, а так же с прицнипами DDD.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Не тестируемые, значит что ты НЕ можешь автоматически проверить корректность кода.
kuj>>Если Вы не можете проверить корректность кода

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

Есть вполне конкретные алгоритмы синтезирования с вполне конкретными детерменированными состояниями. Благозвучность речи, удобство и юзабилити интерфейса пользователя и т.д. — это все проверяется людьми-тестерами.
И вообще какое это все имеет отношение к корпоративным приложениям? Мы говорим о невозможности тестирования ХП в отличии от тестирования CLR-эквивалента.

A>>>Код, который с помошью OpenGL визуализирует карту страны и траекторию движения автомобилей на ней. Ты должен просто сесть и помотреть "то" на экране нарисовано или "не то".
kuj>>Ндааааааа....

Это сильно...

A>Ещё бы, ты ведь дальше своего носа ничего не видел, всё новое тебя удивляет.

Сильно то, что Вы не понимаете ни разу что такое юнит-тестирование.

kuj>>Кто Вам сказал, что юнит-тесты должны проверять благозвучность речи?

A>А где я тут сказал юнит-тесты? Я тут о тестрировании вообще. Ты как всегда что-то не в тему ляпнул.

Вот те раз приехали! Мы ему об автоматическом тестировании кода с помощью юнит-тестов, а он нам ахинею про "тестирование вообще".

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

A>>Есть КУЧА задач, где юнит-тестирование в частности и тестирование вообще не возможно и разглядывание кода (если повезёт, логов) единственный метод отладки. И несмотря ни на что эти задачи успешно решаются.
kuj>Нету никакой кучи задач.

Например, синхронизация многопоточных приложений не поддаётся тестированию. Учи матчасть.

Здравствуйте, kuj, Вы писали:

kuj>Есть вполне конкретные алгоритмы синтезирования с вполне конкретными детерменированными состояниями. Благозвучность речи, удобство и юзабилити интерфейса пользователя и т.д. — это все проверяется людьми-тестерами.

Ты не сладеешь вопросом. синтерз и распознавание речи задачи весьма нетривиальные. Системы самообучающиеся.

kuj>И вообще какое это все имеет отношение к корпоративным приложениям?

Рад представить Microsoft Speech Server.

kuj>Мы говорим о невозможности тестирования ХП в отличии от тестирования CLR-эквивалента.

Возможность есть. Хотя ты её можешь отрицать сколько влезет.

A>>Ещё бы, ты ведь дальше своего носа ничего не видел, всё новое тебя удивляет.
kuj>Сильно то, что Вы не понимаете ни разу что такое юнит-тестирование.

Сильно то, что ты до сих пор не понял, что в этой ветке юнит-тестирование не обсуждается.

kuj>Вот те раз приехали! Мы ему об автоматическом тестировании кода с помощью юнит-тестов, а он нам ахинею про "тестирование вообще".

Мы тут об автоматическом тестировании (не объязательно юнит), а ты неизвестно о чём. Как всегда не отвечаешь,а просто говришь о чём хотелось.

Здравствуйте, adontz, Вы писали:

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

A>Я имел ввиду не добавлять функциональность, а оставлять возможность безболезненного добавления функциональности.

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

... << RSDN@Home 1.2.0 alpha rev. 771>>

Здравствуйте, adontz, Вы писали:

kuj>>Вы сперва определитесь можно ли тестировать ХП или нет.

A>Можно, но не всегда. Как правило — можно.

Хорошо. С этим определились наконец!

Теперь расскажите нам на конкретном примере КАК и какими средствами.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>Ну так расскажите нам КАК Вы тестируете логику? Мы не телепаты — понять Вас без слов не можем.

A>Создаётся некоторая предопределённая база (схема+данные). Натравляется ХП. Проверяется, что данные после исполнения ХП соответствуют ожидаемым.
Проверяете как? на глазок?

А кто Вам сказал, что тестируете Вы именно эту процедуру, а не 10 других процедур, которые она в свою очередь вызывает?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, IT, Вы писали:

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

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

Здравствуйте, kuj, Вы писали:

A>>Создаётся некоторая предопределённая база (схема+данные). Натравляется ХП. Проверяется, что данные после исполнения ХП соответствуют ожидаемым.
kuj>Проверяете как? на глазок?

Нет, проверяется сравнением с эталоном. Не надо задавать дурацкие вопросы, ты меня утомляешь. Это не обсуждение это форменный флуд. Тебе кто-то платит за сообщения побуквенно? Наполни их не байтами, а энтропией.

kuj>А кто Вам сказал, что тестируете Вы именно эту процедуру, а не 10 других процедур, которые она в свою очередь вызывает?

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

Здравствуйте, adontz, Вы писали:

kuj>>А Вы знаете какие функции будут вызваны в конструкторе MessageBox? Честно-честно?
A>Как минимум будет вызван сам конструктор.
Гениально!

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>Есть вполне конкретные алгоритмы синтезирования с вполне конкретными детерменированными состояниями. Благозвучность речи, удобство и юзабилити интерфейса пользователя и т.д. — это все проверяется людьми-тестерами.

A>Ты не сладеешь вопросом. синтерз и распознавание речи задачи весьма нетривиальные. Системы самообучающиеся.

И что с того, что они самообучающиеся? Чем именно это мешает модульному тестированию?

kuj>>И вообще какое это все имеет отношение к корпоративным приложениям?

A>Рад представить Microsoft Speech Server.

Вы разработчик Microsoft Speech Server? А кто Вам сказал, что синтезатор речи был разработан в рамках данного проекта, а не использован один из миллиона ранее написанных?

kuj>>Мы говорим о невозможности тестирования ХП в отличии от тестирования CLR-эквивалента.

A>Возможность есть. Хотя ты её можешь отрицать сколько влезет.

Ну так дайте примеры — аналог того же nUnit, но специально для тестирования ХП. Чтоб конкретнее — для тестирования процедур T-SQL.

A>>>Ещё бы, ты ведь дальше своего носа ничего не видел, всё новое тебя удивляет.
kuj>>Сильно то, что Вы не понимаете ни разу что такое юнит-тестирование.

A>Сильно то, что ты до сих пор не понял, что в этой ветке юнит-тестирование не обсуждается.

Сильно то, что Вы не поняли, что обсуждается именно юнит-тестирование.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Есть КУЧА задач, где юнит-тестирование в частности и тестирование вообще не возможно и разглядывание кода (если повезёт, логов) единственный метод отладки. И несмотря ни на что эти задачи успешно решаются.
kuj>>Нету никакой кучи задач.

A>Например, синхронизация многопоточных приложений не поддаётся тестированию. Учи матчасть.

Во-первых, поддается (в определенных границах). Во-вторых, это синхронизацию потоков Вы называете "кучей задач"? Да, большая куча...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Создаётся некоторая предопределённая база (схема+данные). Натравляется ХП. Проверяется, что данные после исполнения ХП соответствуют ожидаемым.
kuj>>Проверяете как? на глазок?

A>Нет, проверяется сравнением с эталоном.

Чем сравниваете с эталоном. Какими средствами?

kuj>>А кто Вам сказал, что тестируете Вы именно эту процедуру, а не 10 других процедур, которые она в свою очередь вызывает?

A>Никто. ХП редко поддаются юнит-тестированию. Правда это вовсе не означает что тестирование менее полезно или что его сложнее организовать. Хотя отдельную ХП и нельзя выделить, всё таки утверждать что множество зайдествованных ХП абсолютно непредсказуемо тоже нельзя. Вообще я крайне редко видел общие вспомогательные ХП. Если что-то и выделялось в отдельную ХП, то это было очень специфично для вызывающей ХП.

Ну что ж наконец мы определились, что ХП фактически не поддаются тестированию.

На этом считаю вопрос исчерпанным.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:
kuj>Вы знаете как зарабатывать деньги на открытых проектах? Поделитесь знаниями! :D
Кастомизация, потдержка, платная детальная документация. Ты думаешь редхат и им подобные на донэйшены существует

Здравствуйте, kuj, Вы писали:

A>>Например, синхронизация многопоточных приложений не поддаётся тестированию. Учи матчасть.
kuj>Во-первых, поддается (в определенных границах).

Практически не поддаётся. ХП и то лучше тестируются.

kuj>Во-вторых, это синхронизацию потоков Вы называете "кучей задач"? Да, большая куча...

Почитай в словаре Ожегова смысл слова "например".

Здравствуйте, kuj, Вы писали:

kuj>Ну что ж наконец мы определились, что ХП фактически не поддаются тестированию.

Я этого не говорил.

kuj>На этом считаю вопрос исчерпанным.

Ты слышишь только то что хочешь услышать.

Здравствуйте, adontz, Вы писали:

A>>>Например, синхронизация многопоточных приложений не поддаётся тестированию. Учи матчасть.
kuj>>Во-первых, поддается (в определенных границах).

A>Практически не поддаётся. ХП и то лучше тестируются.

Практически-то как-раз поддается. Только Вы об этом ничего не знаете.

kuj>>Во-вторых, это синхронизацию потоков Вы называете "кучей задач"? Да, большая куча...

A>Почитай в словаре Ожегова смысл слова "например".

Я Вас внимательно слушаю. "Огласите пожалуйста весь список!"

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Нахлобуч, Вы писали:

Н>Здравствуйте, Sinclair, Вы писали:

S>>Да-да. Неверящим в императивные языки программирования СУБД рекомендую ознакомиться c dBase/Clipper и посмотреть, как выполнялись всякие джойны и прочее в до-SQL эпоху.

Н>Покажете?
Думаете там будет что-то интересное? На моей памяти это был конкретный геморрой

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kuj, Вы писали:

kuj>>Ну так расскажите нам КАК Вы тестируете логику? Мы не телепаты — понять Вас без слов не можем.

A>Создаётся некоторая предопределённая база (схема+данные). Натравляется ХП. Проверяется, что данные после исполнения ХП соответствуют ожидаемым. Я не думал, что такие вещи надо объяснять.

В таком случае Вы тестируете хрен знает что. Потом наверно ночами сидят твои спецы SQL и гадают на кофейной гуще какая из 400 хранимок сломалась, а то и несколько за раз

. Не завидую ни разработчикам ни тем более пользователям...

Здравствуйте, kejroot, Вы писали:

K>С. Макконнелл: Совершенный код

А это кстати о чём?

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>>Да нет это ты не понял. Разница в том, что люди вовслечены. Для перечисленных задач требует ручное тестирование. Можно и ручное юнит-тестрирование устроить, принципиальной проблемы нет. Важно тут то, что автоматизировать этот процесс не представляется возможным.

A>>В юмор однозначно. Про "ручное юнит тестирование" это твоё изобретение?

A>А почему бы и нет? Например можно прослушивать все расространённые слоги оценивая качество синтезации речи, прежде чем переходить к фразам. Ты вообще увидел сейчас что-то незнакомое и выдал какое-то истеричное "ха-ха". Да, бывает и ручное юнит-тестирование если критерий корректности нельзя проверить автоматически. Вообще напиши что-то сложнее склада, потом и поговорим.
Ты чё та уже совсем заговорился. Не ну всё можно понять, но такое придумать надо иметь богатую фантазию

. Кстати склад пока ещё ни разу не писал, но если ты думаешь, что там сильно проще чем в среднестатистической коммерческой проге, то сильно ошибаешься

Здравствуйте, adontz, Вы писали:

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

Повторряю в сотый раз, юнит тесты тестирую корректность последовательности операторов, корректность кода, и не более чем. То есть насколько ты корректно расположил инструкции (понимаю что тебе мало что приходилось писать, так что ты не очень понимаешь о чём идёт речь), они не проверяют смысловую нагрузку приложения. Ты сначала бы разобрал матчаст что ли, прежде чем такую явную охинею писать. Правда без тебя этот раздел форума был бы скучный и занудный

Здравствуйте, adontz, Вы писали:

A> и разглядывание кода (если повезёт, логов) единственный метод отладки.
Случайно заметьил этот пост

. В твоих мегаприложениях чё, логи формируются тож когда повезёт?

Писчи исчо аффтар

Здравствуйте, kuj, Вы писали:
kuj>а так же с прицнипами DDD.
Кстати вот их то я совсем не догнал

Здравствуйте, Aviator, Вы писали:

A>В таком случае Вы тестируете хрен знает что. Потом наверно ночами сидят твои спецы SQL и гадают на кофейной гуще какая из 400 хранимок сломалась, а то и несколько за раз

. Не завидую ни разработчикам ни тем более пользователям...

Ага, а запускались всё 400. Ты, кончай дураком-то прикидыватся. Неискрене как-то получается.

Здравствуйте, Aviator, Вы писали:

A>Повторряю в сотый раз, юнит тесты тестирую корректность последовательности операторов, корректность кода, и не более чем.

Это определение такое? Браво! Ты ещё раз доказал что понятия не имеешь о чём говоришь.

Здравствуйте, Aviator, Вы писали:

A>> и разглядывание кода (если повезёт, логов) единственный метод отладки.
A>Случайно заметьил этот пост

. В твоих мегаприложениях чё, логи формируются тож когда повезёт?

Писчи исчо аффтар

Мнда. Тебе клоуном работать в цирке.

Здравствуйте, kuj, Вы писали:

A>>Практически не поддаётся. ХП и то лучше тестируются.
kuj>Практически-то как-раз поддается. Только Вы об этом ничего не знаете.

Да ну? Не просвятишь как именно?

kuj>Я Вас внимательно слушаю. "Огласите пожалуйста весь список!"

А зачем? С тобой говорить что об стенку горох, все слова наизнанку выворачиваешь как тебе выгодно. Причём до сих пор ты не произвёл никакого сравнительного анализа, не привёл никакого кода. Сполшные лозунгию. kuj, ты просто пустозвон.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>В таком случае Вы тестируете хрен знает что. Потом наверно ночами сидят твои спецы SQL и гадают на кофейной гуще какая из 400 хранимок сломалась, а то и несколько за раз

. Не завидую ни разработчикам ни тем более пользователям...

A>Ага, а запускались всё 400. Ты, кончай дураком-то прикидыватся. Неискрене как-то получается.
ну ладно, 100

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Aviator, Вы писали:

A>>Повторряю в сотый раз, юнит тесты тестирую корректность последовательности операторов, корректность кода, и не более чем.

A>Это определение такое? Браво! Ты ещё раз доказал что понятия не имеешь о чём говоришь.
да, я просто использую без понятия

Добрый вечер,
Скачал тут несколько примеров на Hibernate и ActiveRecord... Странные впечатления, такое чувство что все это лишнее, но может быть я пока еще не вник. Ну да ладно...

А как все эти Hibernate/ActiveRecord справляются с немаленькими запросами, типа:

UPDATE parts p INNER JOIN manufacturers mf ON (p.ManufacturerID = mf.ShortName) 
INNER JOIN manprice m ON (m.ManufacturerID = mf.ID AND m.PartN = p.PartN) SET p.Description = m.Description 
WHERE Customer = Customer_ AND CustomerOrderN = CustomerOrderN_ AND m.Description IS NOT NULL AND m.Description <> '';

или

SELECT Supplier1, AVG(TIMESTAMPDIFF(HOUR, SupplierOrderDate1, TSDebited)) FROM parts USE INDEX (Supplier1) 
WHERE TIMESTAMPDIFF(DAY, SupplierOrderDate1, TSDebited) < 60 AND OrderType = '' 
AND Supplier1 > 0 AND OrderDebited = true GROUP BY Supplier1;

и т.д.?

Второй вопрос. Может быть кто-нибудь сможет мне выслать примеры своих проектов на repblair @ gmail . com ? Мне чисто в Visual Studio загрузить и посмотреть архитектуру, посмотреть как пишут опытные люди, посмотреть на разных слоях в реальных приложениях. Надеюсь на понимание.

Здравствуйте, Aviator, Вы писали:

A>>Ага, а запускались всё 400. Ты, кончай дураком-то прикидыватся. Неискрене как-то получается.
A>ну ладно, 100

От силы 5.

Здравствуйте, Светлояр, Вы писали:

kuj>>Мда... я не завидую вашим разработчикам БД, но еще больше я не завидую вашим разработчикам BLL...
С>adontz прав, приложение должно разрабатываться по информационной структуре, а не информационная структура по приложению. Вы должны прекрасно понимать, что приложение лишь интерфейс для управления информацией.
А информация без приложения — бессмысленна. Что дальше?

Здравствуйте, Kazna4ey, Вы писали:

K> Скачал тут несколько примеров на Hibernate и ActiveRecord... Странные впечатления, такое чувство что все это лишнее, но может быть я пока еще не вник. Ну да ладно...
K>А как все эти Hibernate/ActiveRecord справляются с немаленькими запросами, типа:
K>

UPDATE parts p INNER JOIN manufacturers mf ON (p.ManufacturerID = mf.ShortName) 
K>INNER JOIN manprice m ON (m.ManufacturerID = mf.ID AND m.PartN = p.PartN) SET p.Description = m.Description 
K>WHERE Customer = Customer_ AND CustomerOrderN = CustomerOrderN_ AND m.Description IS NOT NULL AND m.Description <> '';

Синтаксис UPDATE'а для HQL не помню точно, что-то типа такого:

update Parts p set p.description=p.manufacturer.description where p.manufacturer.description is not null and p.manufacturer.description<>''
или по-другому:
update Parts p inner join p.manufacturer as man set p.description=man.description where man.description is not null and man.description<>''

Причем приятные добавления типа:

update versioned Parts p join ...

Автоматически будет учитываться оптимистическое версирование.

Да, это все для Java — как оно точно в NHibernate не знаю.

Для второго запроса — примерно так же и будет выглядеть. Хотя, вероятнее, проще для такого нативный SQL использовать.

K>Второй вопрос. Может быть кто-нибудь сможет мне выслать примеры своих проектов на repblair @ gmail . com ? Мне чисто в Visual Studio загрузить и посмотреть архитектуру, посмотреть как пишут опытные люди, посмотреть на разных слоях в реальных приложениях. Надеюсь на понимание.
А примеры не пробовал смотреть? PetStore, например.

Здравствуйте, Cyberax, Вы писали:

C>А информация без приложения — бессмысленна. Что дальше?

Информация по определению своему бессмысленной быть не может.

Здравствуйте, Светлояр, Вы писали:

С>Здравствуйте, Cyberax, Вы писали:
C>>А информация без приложения — бессмысленна. Что дальше?
С>Информация по определению своему бессмысленной быть не может.
Может, причем элементарно.

Здравствуйте, Светлояр, Вы писали:

C>>А информация без приложения — бессмысленна. Что дальше?

С>Информация по определению своему бессмысленной быть не может.

И какой смысл Вы вкладываете в информацию?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Практически не поддаётся. ХП и то лучше тестируются.
kuj>>Практически-то как-раз поддается. Только Вы об этом ничего не знаете.

A>Да ну? Не просвятишь как именно?
http://today.java.net/pub/a/today/2003/08/06/multithreadedTests.html
http://www.ibm.com/developerworks/java/library/j-contest.html
и т.д.

kuj>>Я Вас внимательно слушаю. "Огласите пожалуйста весь список!"

A>А зачем?

Затем, что Вы не можете, потому что не знаете и не единожды доказали сей факт. Для подобного Вашему поведения есть специальный термин — 'ламеризм'.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Aviator, Вы писали:

A>> и разглядывание кода (если повезёт, логов) единственный метод отладки.

A>Случайно заметьил этот пост

. В твоих мегаприложениях чё, логи формируются тож когда повезёт?

Писчи исчо аффтар

Говорят, что медитация еще помогает. Но в крайнем случае! В крайнем! Приходиться использовать бубен.....

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Aviator, Вы писали:

kuj>>а так же с прицнипами DDD.

A>Кстати вот их то я совсем не догнал

Если в кратце, то DDD подход упрощает тестирование за счет максимальной изоляции уровня домена от уровня data maping (DAL в простонародии).
Для этих целей, например, используется паттерн Репозиторий (Repository), который выступает посредником между слоями. Такие репозитории можно размещать в отдельных сборках, что еще более упрощает unit-тестирование.

Кроме того еще одним вариантом есть использование IoC-контейнеров (мы используем Spring и Castle Windsor).

В итоге не имеем проблем с TDD подходом для кодирования на весьма большом проекте за исключением вполне естественных проблем на data maping уровне.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

Жжёшь. Это стати не о тестировании многопоточной синхронизации, а о многопоточном тестировании. kuj ты ещё раз доказал что не умеешь читать.

Итого:

kuj не знает что такое бизнес-транзакция.
kuj уверен что мнопоточное тестирование тоже самое, что тестирование многопоточности
kuj верит в миф о серебнянных пулях: TDD, ORM которые сегда везде спасут.
kuj думает, что T-SQL это императивный язык.
kuj не умеет читать. Хотя я не раз приводил интересовавшие его примеры, он кажды раз отрицал их наличие.
kuj не умеет писать. Сам не привёл ни одного вменяемого примера показывающего преимущества А над Б. Даже какой-нибудь гнилой ХП от которой должны были все шарахнутся я и то не увидел.

kuj ты пустозвон. Твоё лексикон ушёл не дальше Эллочки-людоедки. Твои комментарии не содержат абсолютно никакой информации.

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

Возможно вы его утомили глупыми вопросами, просьбами или советами.
Может быть вы обидели его неосторожным высказыванием: задели религиозные, политические, музыкальные и прочие взгляды и вкусы, подвергли критике то, чем adontz дорожит, либо иным образом задели его нежную психику.
Так же вероятно, что вы не вернули долг, не заплатили за работу, отказали в сексуальной близости.
С вами просто не хотят общаться. Такое тоже бывает.
--------------------------------
Что делать?

Вы можете подождать истечения срока бана или написать письмо с извинениями по адресу adontz@mail.ru и возможно adontz изменит своё решение.
--------------------------------

Здравствуйте, adontz, Вы писали:

A>Жжёшь. Это стати не о тестировании многопоточной синхронизации,
Это в том числе и о тестировании синхронизации.

В той мере, в которой ее вообще можно тестировать модульными тестами.

A>kuj думает, что T-SQL это императивный язык.
А Вы все еще так не думаете?

Глупость некоторых индивидов не исправима...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Aviator, Вы писали:

A>Здравствуйте, kejroot, Вы писали:

K>>С. Макконнелл: Совершенный код

A> А это кстати о чём?

ну.. не совсем по теме вопроса, более обще
сам пока не дочитал, и что в новом издании есть не видел

а так, в основном рекоммендации как лучше писать кодд

вот содержание.

вцелом imho чтение полезное, особенно начинающему и среднему программисту

Здравствуйте, adontz, Вы писали:

A>Приблизительно исходя из тех же соображений люди оформляют страховку.

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

... << RSDN@Home 1.2.0 alpha rev. 771>>

Здравствуйте, kuj, Вы писали:

kuj>И какой смысл Вы вкладываете в информацию?

Огромный.

Здравствуйте, Cyberax, Вы писали:

С>>Информация по определению своему бессмысленной быть не может.
C>Может, причем элементарно.

1. Не желаю спорить в этом ключе. Вернёмся к нашим баранам: помойму, необходимо стремиться к тому, чтобы наша информация на любом из уровней оставалась таковой. И в первую очередь об этом заботится СУ этой БД, сохраняя ссылочную и структурную целостность и т.п. Я не прав?
2. Приложение разрабатывается для взаимодействия с пользователем. Оно лишь является одним из возможных вариантов отображения хранимой информации. Я опять не прав?

Здравствуйте, Светлояр, Вы писали:

С>>>Информация по определению своему бессмысленной быть не может.
C>>Может, причем элементарно.

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

Каковой таковой?

С>И в первую очередь об этом заботится СУ этой БД, сохраняя ссылочную и структурную целостность и т.п. Я не прав?

СУБД это склад — хранилище информации. Да, естественно в задачи СУБД входит обеспечение целостности информации, которую она хранит.

С>2. Приложение разрабатывается для взаимодействия с пользователем. Оно лишь является одним из возможных вариантов отображения хранимой информации. Я опять не прав?

Информация в "голом виде" обычно не представляет никакой пользы.

Пример: вы открываете морозильную камеру и видите там кусок замороженного сырого мяса. Станете ли Вы его грызть в таком вот виде?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Светлояр, Вы писали:

kuj>>И какой смысл Вы вкладываете в информацию?

С>Огромный.

И какой же смысл Вы вкладываете в слово 'Огромный'. Что является мерой?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, IT, Вы писали:

A>>Приблизительно исходя из тех же соображений люди оформляют страховку.
IT>В отличии от страховки, твой дизайн будет мешаться под ногами постоянно.

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

Здравствуйте, Светлояр, Вы писали:

С>2. Приложение разрабатывается для взаимодействия с пользователем. Оно лишь является одним из возможных вариантов отображения хранимой информации. Я опять не прав?

Зачем все сразу сводить к пользователю? Приложения это не только формочки и кнопочки! В конце концов, существуют серверные приложения, которые занимаются обработкой данных, но не имеют дел с визуализацией и взаимодействие с пользователем, их работу пользователь вообще не видит или видит опосредованно, через изменения в системе.

Лично для меня при проектировании всегда первична модель данных и бизнес-логика, т.е. адекватное и воспринимаемая человеком модель проблемной области (без привязки к ЯП). Представление объектов модели в конкретном хранилище будь-то субд, объектная база, xml, обычные файлы это вторично. Схема БД — это не информационная модель, а это способ описать отображение этой модели на логические и физические особенности органиации и представления информации в конкретном типе хранилища. Так же как и классы Java, это отражение предметной области средствами языка. Так уж сложилось, что мне, работая в java, при реализации бизнес-логики проще абстрагироваться от физических особенностей хранилища данных, чем если бы я это делал на ХП, поэтому у меня схема БД создается уже после написания классов. Возникает лишь вопрос выбора адекватного способа хранения данных, и не всегда это будет РСУБД.
Если не удается адекватно представить модель данных в хранилище, и способ хранения начинает диктовать изменения в самой модели, стоит подумать о правильности выбора.

Здравствуйте, kuj, Вы писали:

kuj>И какой же смысл Вы вкладываете в слово 'Огромный'. Что является мерой?
Огромность.

Здравствуйте, Trean, Вы писали:

T>Если не удается адекватно представить модель данных в хранилище, и способ хранения начинает диктовать изменения в самой модели, стоит подумать о правильности выбора.

Хм, не вижу таких задач. Есть примеры?

Здравствуйте, adontz, Вы писали:

A>Я не говорю что такие манипуляции надо проводить всегда, но для меня очевидно, что объекту-пользователю свойства добавят с очень большой вероятностью, а объекту-накладной свойства добавят с практически нулевой вероятностью.

Кто добавит?

... << RSDN@Home 1.2.0 alpha rev. 771>>

Здравствуйте, Kazna4ey, Вы писали:

K>Здравствуйте, Aviator, Вы писали:

A>>смотрел это?

K>Да, смотрел, спасибо большое. Но хотелось бы примеры кода (желательно не по 2 строчки) со всех слоев, чтобы увидеть цепочку и понять общую логику, вот например в своем вопросе я привел примеры и думаю абсолютно всем понятно как я строю свое приложение. Вот и мне (и думаю не только мне) хотелось быть понять как вы строите свои приложения (и увидеть это на примерах а не абстрактных выражениях). Большинство из вас работает в командах, вы можете учиться друг у друга, а человеку который работает удаленно или выполняет проект один может быть достаточно проблематично узнать, "а как же делают там"? Я думаю что в принципе я задал вполне конкретный вопрос, — показать примеры с разных слоев, чтобы можно было понять как вы строите свои приложения. Надеюсь кто-то отвлекется от спора и уделит несколько минут на это.

Присоединяюсь к вопросу.
Что вы человека всякой абстракцией да литературой грузите

Ради бога, почему не привести понятные кусочки кода в 5-10 строк с каждого "уровня"?
Можно же наверное в двух словах показать, как это выглядит У ВАС?

Это.. Как там... "Занятие включает рассказ, показ, тренировку", ага

Здравствуйте, bnk, Вы писали:

bnk>Присоединяюсь к вопросу.
bnk>Что вы человека всякой абстракцией да литературой грузите

bnk>Ради бога, почему не привести понятные кусочки кода в 5-10 строк с каждого "уровня"?
bnk>Можно же наверное в двух словах показать, как это выглядит У ВАС?
bnk>

bnk>Это.. Как там... "Занятие включает рассказ, показ, тренировку", ага
bnk>

Присоединяюсь. Очень интересно посмотреть как пишут люди с более высоким опытом.

Здравствуйте, kuj, Вы писали:

kuj>Каковой таковой?
Информацией.

kuj>Информация в "голом виде" обычно не представляет никакой пользы.
Согласен. Но я клоню к тому, что удалив ПО, БД должна сохранить модель предметной области, а не отношение классов, которые мы спроектировали в процессе разработки ПО.

kuj>Пример: вы открываете морозильную камеру и видите там кусок замороженного сырого мяса. Станете ли Вы его грызть в таком вот виде?

Ну, это будет зависеть от степени оголодания.

Здравствуйте, Светлояр, Вы писали:

С>Здравствуйте, Trean, Вы писали:

T>>Если не удается адекватно представить модель данных в хранилище, и способ хранения начинает диктовать изменения в самой модели, стоит подумать о правильности выбора.

С>Хм, не вижу таких задач. Есть примеры?

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

"Queries for historical data, replete with time ranges and roll ups and arbitrary time zone conversions are difficult in a relational database. Compositions of those rules are even more difficult. This is a problem compounded by the free nature of relational systems themselves. Many relational systems are often not modelled correctly with respect to time series data."

http://en.wikipedia.org/wiki/Time_series_database

bnk>>Присоединяюсь к вопросу.
bnk>>Что вы человека всякой абстракцией да литературой грузите

bnk>>Ради бога, почему не привести понятные кусочки кода в 5-10 строк с каждого "уровня"?
bnk>>Можно же наверное в двух словах показать, как это выглядит У ВАС?
bnk>>

bnk>>Это.. Как там... "Занятие включает рассказ, показ, тренировку", ага
bnk>>

MC>Присоединяюсь. Очень интересно посмотреть как пишут люди с более высоким опытом.

А можно и я присоединюсь?

300 постов и НИ 1-го конкретного полного ответа на мои вопросы.

Здравствуйте, Светлояр, Вы писали:

С>Здравствуйте, kuj, Вы писали:

kuj>>Каковой таковой?
С>Информацией.

kuj>>Информация в "голом виде" обычно не представляет никакой пользы.
С>Согласен. Но я клоню к тому, что удалив ПО, БД должна сохранить модель предметной области, а не отношение классов, которые мы спроектировали в процессе разработки ПО.

Отношения классов, это лишь отражение отношений сущностей предметной области. Если связь между объектами существует, в БД вы от нее не избавитесь, но вот представить средствами БД (как и средсвами ЯП) можно различными способами. Почему я и говорю, что модель данных предметной области != схема БД.

К слову, упоминавшийся Hibernate позволяет реализовать наследование классов в БД по крайней мере тремя различными способами. Так же он позволяет указывать custom type mapping для полей класса, кроме того можно разнести разные поля класса по разным таблицам. Остается простор для оптимизации, но бизнес-логика от механизма хранения данных максимально абстрагируется. В 90% случаев этого достаточно, чтобы минимизировать несоответствие между тем как информация представлена в классах и как в БД. Если не удается хорошо представить предметную область в конкретном ЯП можно поискать другой более выразительный. Если кому-то удобнее работать с объектами предметной области с помощью SQL и ХП и это удовлетворяет всем требованиям к продукту, то ради бога. Но, что, касается меня, database-centric подход мне не нравится.

Здравствуйте, IT, Вы писали:

A>>Я не говорю что такие манипуляции надо проводить всегда, но для меня очевидно, что объекту-пользователю свойства добавят с очень большой вероятностью, а объекту-накладной свойства добавят с практически нулевой вероятностью.
IT>Кто добавит?

Ну вот изменилось ТЗ (добавилась/изменилась функциональность) и кто-то (скажем, Архитектор, хотя не суть) добавил. Вот хороший был пример с секретным вопросом для восстановления доступа. В моей схеме БД вообще не затрагивается, даже DAL может не затрагиватся если оперирует только с коллекцией Dictionary<string, string> Properties. А так, пришлось бы столбец добавлять.

Здравствуйте, Trean, Вы писали:

T>Почему я и говорю, что модель данных предметной области != схема БД.

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

модель данных предметной области -> иерархия классов -> схема БД.

T>К слову, упоминавшийся Hibernate позволяет реализовать наследование классов в БД по крайней мере тремя различными способами. Так же он позволяет указывать custom type mapping для полей класса, кроме того можно разнести разные поля класса по разным таблицам. Остается простор для оптимизации, но бизнес-логика от механизма хранения данных максимально абстрагируется. В 90% случаев этого достаточно, чтобы минимизировать несоответствие между тем как информация представлена в классах и как в БД. Если не удается хорошо представить предметную область в конкретном ЯП можно поискать другой более выразительный. Если кому-то удобнее работать с объектами предметной области с помощью SQL и ХП и это удовлетворяет всем требованиям к продукту, то ради бога. Но, что, касается меня, database-centric подход мне не нравится.

Hibernate как и любая ORM это обощённое средство. Оно ничего не знает о смысле данных, только о структуре.

Вот пример из реальной жизни:
Была табличка с пользователями Users

ID	Login	Password	FirstName	LastName	DateOfBirth
1	admin	...	John	Doe	01/02/1972
2	user	...	Mary	Smith	03/04/1981

которую постоянно меняли. Когда это надоело переделали так
Users

ID	Login	Password
1	admin	...
2	user	...

UserProperties

ID	Name	Value
1	FirstName	John
1	LastName	Doe
1	DateOfBirth	01/02/1972
2	FirstName	Mary
2	LastName	Smith
2	DateOfBirth	03/04/1981

Таблицы с тех пор больше не перестраивались, наступило временное счастье.
Чуть позже выяснилось, что для инициализации объекта теперь требуется не один запрос к БД, а [количество полей + 1]. Это естестенно. На практике пришлось от автоматического мапинга отказатся, руками выгребать все User Properties для которых совпадал ID и раскидывать значения по полям класса руками. Так быстрее.
Конечно данную задачу можно решить и по-другому: кешированием. Кеширование объектов User снизило бы нагрузку на БД, только это не решение, а скрытие проблемы, работающее иногда. Если кешируемые объекты часто меняются (запрашиваются только для редактирования, например, SELECT и UPDATE будет поровну), кеш только ухудшит производительность. Проблему UPDATE это тоже не решает. Одно сохранение объекта выливается в [количество полей + 1] запросов в транзакции, вместо одного.

Подобные проблемы, я считаю разумным решать через ХП, скрывающие структуру БД. Пользователь БД не знает одна у него таблица хранит сущность (в данном случае User) или она разбросана по нескольким таблицам. Более того, при изменении переписывается ХП, но не тот, кто её использует. Переносить это выше, в DAL, не разумно так как у нас особенности структуры БД теперь светятся в двух разных местах (на SQL — схема, на Java/C#/C++ — запросы) на двух разных языках и это надо регулярно синхронизировать.

Иногда, на простых данных ORM действительно выдают что-то близкое идеалу. Часто, на не очень сложных данных, ORM выдают что-то относительно приемлемое. Но стоит продумать схему БД как следует, чтобы это была действительно хорошая схема, а не тормоз или монолит и всё что нагенерировали ORM приходится выкидывать. Вот потому я и считаю, что действительно перспективным и правильным является отображать Relational в Object, а не наоборот как сейчас и поступают.

Здравствуйте, kuj, Вы писали:

kuj>>>а так же с прицнипами DDD.

A>>Кстати вот их то я совсем не догнал

kuj>Если в кратце, то DDD подход упрощает тестирование за счет максимальной изоляции уровня домена от уровня data maping (DAL в простонародии).

kuj>Для этих целей, например, используется паттерн Репозиторий (Repository), который выступает посредником между слоями. Такие репозитории можно размещать в отдельных сборках, что еще более упрощает unit-тестирование.

kuj>Кроме того еще одним вариантом есть использование IoC-контейнеров (мы используем Spring и Castle Windsor).

kuj>В итоге не имеем проблем с TDD подходом для кодирования на весьма большом проекте за исключением вполне естественных проблем на data maping уровне.
C репозитарием много непоняток. Писать кучу функций типа
IList<Order> GetOrdersByDateAndCustomer()
со всеми возможными комбинациями, которых может быть прилично+ новые подятся постоянно не очень хочеться. Постепенно приходим к осознанию необходимости Query object. А писать самому query object неразумно, лучше уж тогда задействовать средства того же хибернета. Так что изоляцию от полная изоляция от сторонних средств и персистентного слоя нет. Плюс коллекции хибернета нарушают PI.

Здравствуйте, Kazna4ey, Вы писали:

K>А можно и я присоединюсь?

300 постов и НИ 1-го конкретного полного ответа на мои вопросы.

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

Итак, у нас есть обработчик кнопки

Это Presentation Layer. Не важно Model-View-Controller или Document-View у тебя всегда есть нечто, что надо дёрнуть: Model или Document. В первом случае обработчик кнопки это View, во втором — controller. Вообще говоря, и Model, и Document совсем не объязаны быть именно одним объектом. Это просто некоторые абстракции, разделяющие функциональность удобным образом. Надо понять что есть в твоём приложении Document. Пусть название не смущает, речь не о чём-то что печатается, а о сущностях, которыми оперирует приложение. Например, для программы учёта трафика Document будет (может быть) совокупностью пользователей, сетевых интерфейсов, замеров расхода трафика, таблиц соответствия пользователей IP адресам в момент времени. Вся эта информация будет представлена в виде объектов некоторых классов — бизнес объектов. Если у тебя приложение содержит одно звено (tier), то есть большой соблазн запихать бизнес-логику в обработчик кнопки. Очень желательно всё таки сдержаться и выделить всю логику относящуюся к обработке информации, но не отображению в бизнес-объекты. Скажем, если вернуться к примеру выше, то проверка корректности введённого IP адреса (что частей четыре и все они меньше, чем 256) это задача Presenation Layer и, хотя я бы написал валидатор, особой трагедии в том, что подобная проверка находится в обработчике кнопки ОК нет. А вот проверка что IP адрес соответствует какому-либо пользователю (получение спска пользователей, которым соответствует IP адрес) это уже задача обработки информации, а не отображения и её надо выделять в Business Logic Layer. Если у тебя многозвенная архитектура (multi-tier, клиент-сервер, трёзвенка), то сущесвенная часть Business Logic может располагатся не на клиенте (последнее звено), а выше. Разговор о том как, где и что делать долгий, сложный и выходит за рамки сообщения форума. Business Logic Layer работает с бизнес-объектами, но не их постоянным хранилищем. То есть сохранять список пользоватейлей в файл Business Logic не умеет. Эти задачи выделяются в Data Access Layer (в multi-tier он обычно в последнем звене, хотя могут быть и промежуточные хранилища служащие разным целям, например, кешированию). Именно Data Access Layer занимается чтением данных из хранилища (файл, БД, удалённое хранилище с доступом по HTTP, и т.д.) и записью их обратно. В случае одного звена DAL отдаёт и принимает сразу BO (Business Objects) с которыми приложение и работает. В случае нескольких звеньев DAL может выдавать DTO (Data Transfer Objects) задача которых — это перенос структурированной информации между звеньями. Если DTO и BO очень похожи, то бывает в качестве BO используют DTO реализуя логику во внешних классах-манипутяторах. Это имеет то преимущество, что нет переноса информации из DTO в BO и обратно. Недостаток — большая угроза потери инкапсуляции.

Как-то сумбурно вышло, спрашивай если что, какашки всё равно закончились.

Здравствуйте, Kazna4ey, Вы писали:

bnk>>>Присоединяюсь к вопросу.
bnk>>>Что вы человека всякой абстракцией да литературой грузите

bnk>>>Ради бога, почему не привести понятные кусочки кода в 5-10 строк с каждого "уровня"?
bnk>>>Можно же наверное в двух словах показать, как это выглядит У ВАС?
bnk>>>

bnk>>>Это.. Как там... "Занятие включает рассказ, показ, тренировку", ага
bnk>>>

MC>>Присоединяюсь. Очень интересно посмотреть как пишут люди с более высоким опытом.

K>А можно и я присоединюсь?

300 постов и НИ 1-го конкретного полного ответа на мои вопросы.
нормальные бюли ответы. Если вы ожидаете, что кто-то подготовит отрывки из проектов, упросчтит их, снадбит подробными разъяснениями то это наврятли... Вот например примерчег здесь. Куча всего интересного есть здесь, а вы всё ждёте пока вам всё разжуют...

Здравствуйте, kuj, Вы писали:

kuj>Это в том числе и о тестировании синхронизации.

В той мере, в которой ее вообще можно тестировать модульными тестами.
Интересно как ты будешь модульными тестами ловить deadlock, starvation, race condition итп?

... << RSDN@Home 1.2.0 alpha rev. 745>>

Здравствуйте, adontz, Вы писали:

A>kuj думает, что T-SQL это императивный язык.
Вобщето таки императивный.

USE AdventureWorks;
GO
DECLARE @tablename sysname
SET @tablename = N'Person.AddressType'
table_loop:
   IF (@@FETCH_STATUS <> -2)
   BEGIN   
      SELECT @tablename = RTRIM(UPPER(@tablename)) 
      EXEC ('SELECT ''' + @tablename + ''' = COUNT(*) FROM '
            + @tablename )
      PRINT '  '
   END
   FETCH NEXT FROM tnames_cursor INTO @tablename
IF (@@FETCH_STATUS <> -1) GOTO table_loop
GO

(C)MSDN

... << RSDN@Home 1.2.0 alpha rev. 745>>

Здравствуйте, WolfHound, Вы писали:

kuj>>Это в том числе и о тестировании синхронизации.

В той мере, в которой ее вообще можно тестировать модульными тестами.
WH>Интересно как ты будешь модульными тестами ловить deadlock, starvation, race condition итп?

Никак не будет. Мсье — фантазёр. Ошибки синхронизации ловятся обёрткой примитивов синхронизации и распечаткой лога обращений к примитиву блокирующему поток. У Рихтера, кажется, есть такое для отладки CriticalSection. Но это самые сложные случаи, а вообще это отлаживается интуитивно

Опыт решает.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, adontz, Вы писали:

A>>kuj думает, что T-SQL это императивный язык.
WH>Вобщето таки императивный.

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

Здравствуйте, adontz, Вы писали:

A>Никак не будет. Мсье — фантазёр. Ошибки синхронизации ловятся обёрткой примитивов синхронизации и распечаткой лога обращений к примитиву блокирующему поток. У Рихтера, кажется, есть такое для отладки CriticalSection.
Логами можно только deadlock поймать.
A>Но это самые сложные случаи, а вообще это отлаживается интуитивно

Опыт решает.
starvation и race condition только медитацией над кодом.
И если найти race condition довольно легко (настолько легко что их у меня не бывает) то ловить starvation реальный хардкор.

... << RSDN@Home 1.2.0 alpha rev. 745>>

Здравствуйте, WolfHound, Вы писали:

WH>И если найти race condition довольно легко (настолько легко что их у меня не бывает)

Тоже не всегда. Под отладчиком половина проблем пропадает, начинаешь писать логи, сбивается время исполнения, половина проблем пропадает. В итоге сидишь и угадываешь.

WH>то ловить starvation реальный хардкор.

starvation не deadlock, но очень похож. Если ловить слишком долго ждущие потоки, то из логов что-то можно вытянуть. Хотя нестабильность ситуации делает своё дело и мусора в логах выше крыши. Проще помедитировать.

Здравствуйте, adontz, Вы писали:

A>starvation не deadlock, но очень похож.
Не ставь в один ряд deadlock и starvation.
deadlock штука примитивная. Их ловить очень легко. Их можно просто на бумажке нарисовать.
А вот starvation штука реально противная. Если мне кто раскажет как ловить starvation'ы буду очень благодарен.

... << RSDN@Home 1.2.0 alpha rev. 745>>

Здравствуйте, WolfHound, Вы писали:

WH>Не ставь в один ряд deadlock и starvation.
WH>deadlock штука примитивная. Их ловить очень легко. Их можно просто на бумажке нарисовать.
WH>А вот starvation штука реально противная. Если мне кто раскажет как ловить starvation'ы буду очень благодарен.

Я и не ставлю. В дедлоке поток ждёт навсегда, в старвайшене дольше чем полагается. Когда это дольше выражается 1-10 секундами простоя (пусть и иногда), отловить такие моменты можно (дедлоки тоже ловятся по принципу, кто ждёт больше 60 секунд, тот крайний). Если же у тебя 3мс вместо 1мс, то да, ты в жопе

Только медитация.
Особенно забавно когда с голоданием борются увеличением потоков в пуле. Потом видим каменты к ревизии "500 потоков в пуле не хватало, сделал 1000".

Здравствуйте, WolfHound, Вы писали:

A>>Но это самые сложные случаи, а вообще это отлаживается интуитивно

Опыт решает.
WH>starvation и race condition только медитацией над кодом.
WH>И если найти race condition довольно легко (настолько легко что их у меня не бывает) то ловить starvation реальный хардкор.
Вообще говоря, starvation и lock contention можно было бы в большинстве случаев тоже достаточно легко находить, если была бы возможность инструментировать локи и смотреть на котором из них больше всего contender'ов висят.

В Java такое есть — недавно всю крутость ощутил. В .NET/C++ тоже ничего не мешает добавить.

Здравствуйте, Cyberax, Вы писали:

C>Вообще говоря, starvation и lock contention можно было бы в большинстве случаев тоже достаточно легко находить, если была бы возможность инструментировать локи и смотреть на котором из них больше всего contender'ов висят.
C>В Java такое есть — недавно всю крутость ощутил. В .NET/C++ тоже ничего не мешает добавить.

Хммм идея для меня новая, интересно. Правда боюсь опять будет информационный мусор в виде примитивов синхронизации, которых часто ожидают, но малый период времени (скажем ноль, Wait тут же возвратил управление).
В любом случае звучит первспективно. Захотелось добавить в .Net

Здравствуйте, adontz, Вы писали:

[skip]
A>Таблицы с тех пор больше не перестраивались, наступило временное счастье.
A>Чуть позже выяснилось, что для инициализации объекта теперь требуется не один запрос к БД, а [количество полей + 1]. Это естестенно. На практике пришлось от автоматического мапинга отказатся, руками выгребать все User Properties для которых совпадал ID и раскидывать значения по полям класса руками. Так быстрее.
Эээ... ORM точно так же может:

public class UserProperties
{
   private final static String NAME_KEY="Name";
   private Map<String,String> storageMap;

   //Приватные, так как клиенты класса не должны напрямую трогать эту карту.
   private Map<String,String> getStorageMap() {return storageMap;}
   private void setStorageMap(Map<String,String> map) {return this.storageMap=map;}

   public void setFirstName(String name)
   {
       storageMap.set(UserProperties.NAME_KEY,name);
   }
   public void setFirstName()
   {
       return storageMap.get(UserProperties.NAME_KEY);
   }
   ...
}

//В мэппинге
...
<map name="storageMap" cascade="all-delete-orphan" lazy="false" fetch="join">
   <key column="id"/>
   <map-key column="name" type="string" length="32"/>
   <element column="value" type="string" length="128"/>
</map>
...

Выделенное — если нужна неленивая загрузка.

A>Конечно данную задачу можно решить и по-другому: кешированием. Кеширование объектов User снизило бы нагрузку на БД, только это не решение, а скрытие проблемы, работающее иногда. Если кешируемые объекты часто меняются (запрашиваются только для редактирования, например, SELECT и UPDATE будет поровну), кеш только ухудшит производительность. Проблему UPDATE это тоже не решает. Одно сохранение объекта выливается в [количество полей + 1] запросов в транзакции, вместо одного.
Для частоменяющихся объектов просто нужен хороший кэш. Ну и количество запросов будет вполне обычным, т.е. не отличающимся от ручного случая. Ну и всегда можно оптимизировать все — Hibernate позволяет использовать ХП для работы с коллекциями.

Здравствуйте, Cyberax, Вы писали:

C> private final static String NAME_KEY="Name";
C> private Map<String,String> storageMap;

Это типа нормальное решение ты считаешь? Перенести работу DAL в Business Object. С какой стати класс User должен знать как он хранится в БД?

Не-не, это всё заплатки и хаки лишь бы не писать руками DAL.

Здравствуйте, WolfHound, Вы писали:

kuj>>Это в том числе и о тестировании синхронизации.

В той мере, в которой ее вообще можно тестировать модульными тестами.
WH>Интересно как ты будешь модульными тестами ловить deadlock, starvation, race condition итп?

Это не задача модульных тестов.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

K>>А можно и я присоединюсь?

300 постов и НИ 1-го конкретного полного ответа на мои вопросы.

A>Нечего удивлятся. Кинуть какашкой в ближнего гораздо интереснее, чем отвечать на вопрос.

Очередная порция чуши:

A>Итак, у нас есть обработчик кнопки

Это Presentation Layer. Не важно Model-View-Controller или Document-View у тебя всегда есть нечто, что надо дёрнуть: Model или Document. В первом случае обработчик кнопки это View, во втором — controller.

WinForms это не MVC, ни MVP, ни Document-View. Формы (визуальные контроллы) WinForms инкапсулируют функциональность и поведение и Controller`а и View в одном классе.

А Document-View это, например, MFC — с четким разделением на классы CView и CDocument.

A>Вообще говоря, и Model, и Document совсем не объязаны быть именно одним объектом.

Это ты только что придумал? Model-Document архитектура? Сильно...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

C>> private final static String NAME_KEY="Name";
C>> private Map<String,String> storageMap;
A>Это типа нормальное решение ты считаешь? Перенести работу DAL в Business Object. С какой стати класс User должен знать как он хранится в БД?
Ну ладно, можешь сделать custom type — но там просто больше boilerplate-кода (кроме того, я не помню как его использовать, а в доку лень лезть).

А вообще — я бы не стал такой хак делать, а просто отдавал бы клиентам storageMap — нефиг скрывать такие детали доступа.

A>Не-не, это всё заплатки и хаки лишь бы не писать руками DAL.
Так этот объект — это ЧАСТЬ DAL.

Здравствуйте, Kazna4ey, Вы писали:

10000 строк кода? Да это не много. Ну в том смысле, что 10000 строк можно полностью перелопатить и не трястись от страха, что что-то забыл.

В вопросах обобщения действует чего-либо действует одно, но мощное правило:
1. Либо ты долго пишешь библиотеку, с помощью которой быстро решаешь определенный круг задач.
2. Либо ты берешь стандартный способ общения с БД, который прописан твоей средой разработки, и решаешь задачу стандартно.

У всего есть недостатки и преимущества.

Я использую первый вар-т. Но я свой MLObject (это наимощнейший предок на 30к строк) разрабатывал долго в частности в свое время — ну перло меня от этого. Он мощен неимоверно, но решает достаточно узкий круг задач бухучетной тематики.
Недостатком моего случая является тот факт, что носитель информации — автор, т.е. я. Есть какая-то обрывочная дока. Но на полноценную доку нет времени. Вот ушел сотрудник, который кроме меня знал мою библиотеку. Сейчас буду садиться за доку.

У второго вар-та тоже есть недостатки. Например, несистемность. Со временем подходы к использования станд. библиотеки разбредаются: здесь один подход, а в модуле, который писал другой программист, другой подход. Хотя проблемы несогласованности решаются административными методами.

Тебе же самому решать как быть: вар-т 1 или 2.

Здравствуйте, Aviator, Вы писали:

A>>>Кстати вот их то я совсем не догнал

kuj>>Если в кратце, то DDD подход упрощает тестирование за счет максимальной изоляции уровня домена от уровня data maping (DAL в простонародии).

kuj>>Для этих целей, например, используется паттерн Репозиторий (Repository), который выступает посредником между слоями. Такие репозитории можно размещать в отдельных сборках, что еще более упрощает unit-тестирование.

kuj>>Кроме того еще одним вариантом есть использование IoC-контейнеров (мы используем Spring и Castle Windsor).

kuj>>В итоге не имеем проблем с TDD подходом для кодирования на весьма большом проекте за исключением вполне естественных проблем на data maping уровне.

A>C репозитарием много непоняток. Писать кучу функций типа
A> IList<Order> GetOrdersByDateAndCustomer()
A>со всеми возможными комбинациями, которых может быть прилично+ новые подятся постоянно не очень хочеться.

А так примерно и получается. Зато BLL это именно BLL, который ничего о других слоях не знает и знать не хочет.

A>Постепенно приходим к осознанию необходимости Query object.

Ни в коем случае!

A>А писать самому query object неразумно, лучше уж тогда задействовать средства того же хибернета.

Hibernate нельзя...

A>Так что изоляцию от полная изоляция от сторонних средств и персистентного слоя нет.

Конечно больше приходится кодировать, зато окупается сполна. Например, у нас есть проектик (пока не большой, но перспективный), в котором три разных DAL, используемых в трех разных конфигурациях.

A>Плюс коллекции хибернета нарушают PI.

Не совсем понял. Разъясните пожалуйста.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

Написал было ответ, но потом вспомнил что ты забанен и передумал. Да и о чём говорить с человеком, который фразу
Вообще говоря, и Model, и Document совсем не объязаны быть именно одним объектом.
не смог прочесть как
Вообще говоря, и Model в MVC, и Document в Document-View совсем не объязаны быть именно одним объектом.
что было очевидно, учитывая контекст.

Просто даю тебе шанс высказаться на ту же тему самому и чтоб не как у меня. Тебе ведь есть что написать да? Не жалкие, нелепо выглядящие, придирки к чужому тексту, а свой.

Здравствуйте, Cyberax, Вы писали:

C>А вообще — я бы не стал такой хак делать, а просто отдавал бы клиентам storageMap — нефиг скрывать такие детали доступа.

На то они и детали, чтоб скрывать.

A>>Не-не, это всё заплатки и хаки лишь бы не писать руками DAL.
C>Так этот объект — это ЧАСТЬ DAL.

Я думал, что User в данном случае BO.

BO — часть DAL звучит как-то странно. BO возвращается DAL, но от DAL зависеть не должен.

Здравствуйте, adontz, Вы писали:

C>>В Java такое есть — недавно всю крутость ощутил. В .NET/C++ тоже ничего не мешает добавить.
A>Хммм идея для меня новая, интересно. Правда боюсь опять будет информационный мусор в виде примитивов синхронизации, которых часто ожидают, но малый период времени (скажем ноль, Wait тут же возвратил управление).
A>В любом случае звучит первспективно. Захотелось добавить в .Net

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

Это все сценарии starvation'а, естественно, не покроет. Но мне оно помогло найти злобный лок, из-за которого весь сервер тормозил.

Здравствуйте, Aviator, Вы писали:

A>Типа того. BLT — вобщем кустарная штука. Hibernate — один из признанных промышленных реализаций. LINQ — этот интеграция языка запросов и всей инфраструктуры ORM в компилятор языка, что позволяет получить проверку запроса на этапе компиляции. Плюс Linq унифицирует доступ к разнородным провайдерам даннх, т.е. к СУБД, коллекциям,...

Какие есть ORM для С++, пригодные для использования? В частности интересует поддерживающие sqlite.

Здравствуйте, adontz, Вы писали:

C>>А вообще — я бы не стал такой хак делать, а просто отдавал бы клиентам storageMap — нефиг скрывать такие детали доступа.
A>На то они и детали, чтоб скрывать.
Ты уж разберись — скрывать или нет

A>>>Не-не, это всё заплатки и хаки лишь бы не писать руками DAL.
C>>Так этот объект — это ЧАСТЬ DAL.
A>Я думал, что User в данном случае BO.

Нет, это часть слоя доступа к данным

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

A>BO — часть DAL звучит как-то странно. BO возвращается DAL, но от DAL зависеть не должен.
А у нас нет зависимости UserProperties от DAL. Для клиентов класса методы setName/getName работают абсолютно прозрачно, а то что они используют для хранения внутреннюю карту — так это личное дело объекта.

Ну и как я сказал — даже от этого можно избавится, но придется писать дополнительный код.

Здравствуйте, nicolas1, Вы писали:

A>>Типа того. BLT — вобщем кустарная штука. Hibernate — один из признанных промышленных реализаций. LINQ — этот интеграция языка запросов и всей инфраструктуры ORM в компилятор языка, что позволяет получить проверку запроса на этапе компиляции. Плюс Linq унифицирует доступ к разнородным провайдерам даннх, т.е. к СУБД, коллекциям,...
N>Какие есть ORM для С++, пригодные для использования? В частности интересует поддерживающие sqlite.
Нет. Максимум что видел: http://dtemplatelib.sourceforge.net/dtl_introduction.htm

Здравствуйте, Cyberax, Вы писали:

C>У меня в объектах-сущностях нет никакой логики (за исключением тривиальных хелперов).

Ага, да, встречался уже. ХЗ, особенных преимуществ я в таком подходе не нашёл, недостатков тоже. создалось впечатление что это в большей степени дело вкуса.

C>А у нас нет зависимости UserProperties от DAL. Для клиентов класса методы setName/getName работают абсолютно прозрачно, а то что они используют для хранения внутреннюю карту — так это личное дело объекта.

Есть архитектурная зависимость, скажем в XML-храниище карта будет не нужна. То есть поля класса User хранятся кучно торчит наружу слишком сильно.

C>Ну и как я сказал — даже от этого можно избавится, но придется писать дополнительный код.

Ну вот и я пишу дополнительный код, но в виде ХП.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Cyberax, Вы писали:
C>>У меня в объектах-сущностях нет никакой логики (за исключением тривиальных хелперов).
A>Ага, да, встречался уже. ХЗ, особенных преимуществ я в таком подходе не нашёл, недостатков тоже. создалось впечатление что это в большей степени дело вкуса.
Есть очень большое преимущество — код можно выделить в отдельную библиотеку, разделяемую разными проектами.

C>>А у нас нет зависимости UserProperties от DAL. Для клиентов класса методы setName/getName работают абсолютно прозрачно, а то что они используют для хранения внутреннюю карту — так это личное дело объекта.
A>Есть архитектурная зависимость, скажем в XML-храниище карта будет не нужна. То есть поля класса User хранятся кучно торчит наружу слишком сильно.
Для XML и другие структуры данных часто нужны. Так что это еще отдельный вопрос.

C>>Ну и как я сказал — даже от этого можно избавится, но придется писать дополнительный код.
A>Ну вот и я пишу дополнительный код, но в виде ХП.
Так ты его пишешь для ВСЕГО, а мне он только для некоторых "некрасивых" объектов нужен.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Trean, Вы писали:

T>>Почему я и говорю, что модель данных предметной области != схема БД.

A>Правда, модель данных предметной области != иерархия классов. Суть же мысли в том, чтобы не играть в испорченный телефон при построении БД.

A>модель данных предметной области -> иерархия классов -> схема БД.

T>>К слову, упоминавшийся Hibernate позволяет реализовать наследование классов в БД по крайней мере тремя различными способами. Так же он позволяет указывать custom type mapping для полей класса, кроме того можно разнести разные поля класса по разным таблицам. Остается простор для оптимизации, но бизнес-логика от механизма хранения данных максимально абстрагируется. В 90% случаев этого достаточно, чтобы минимизировать несоответствие между тем как информация представлена в классах и как в БД. Если не удается хорошо представить предметную область в конкретном ЯП можно поискать другой более выразительный. Если кому-то удобнее работать с объектами предметной области с помощью SQL и ХП и это удовлетворяет всем требованиям к продукту, то ради бога. Но, что, касается меня, database-centric подход мне не нравится.

A>Hibernate как и любая ORM это обощённое средство. Оно ничего не знает о смысле данных, только о структуре.

A>Вот пример из реальной жизни:
A>Была табличка с пользователями Users
A>
A>
A>
A>
A>

ID	Login	Password	FirstName	LastName	DateOfBirth
1	admin	...	John	Doe	01/02/1972
2	user	...	Mary	Smith	03/04/1981

A>которую постоянно меняли. Когда это надоело переделали так
A>Users
A>
A>
A>
A>
A>

ID	Login	Password
1	admin	...
2	user	...

A>UserProperties
A>
A>
A>
A>
A>
A>
A>
A>
A>

ID	Name	Value
1	FirstName	John
1	LastName	Doe
1	DateOfBirth	01/02/1972
2	FirstName	Mary
2	LastName	Smith
2	DateOfBirth	03/04/1981

A>Таблицы с тех пор больше не перестраивались, наступило временное счастье.

Ха-ха, так в ряде случаев такая структура — известный анти-паттерн, есть даже для нее название, но я к сожалению не могу припомнить его. Структура запросов с джойнами, агрегатами настолько усложняется, что ну его нафиг. Для системы к которой предъявляются требования по выскокой производительности — такая денормализованная структура bad practice. Вот для CMS какой-нибудь — нормально, так сделано в Alfresco CMS (кстати тоже через Hibernate).

A>Чуть позже выяснилось, что для инициализации объекта теперь требуется не один запрос к БД, а [количество полей + 1]. Это естестенно. На практике пришлось от автоматического мапинга отказатся, руками выгребать все User Properties для которых совпадал ID и раскидывать значения по полям класса руками. Так быстрее.
A>Конечно данную задачу можно решить и по-другому: кешированием. Кеширование объектов User снизило бы нагрузку на БД, только это не решение, а скрытие проблемы, работающее иногда. Если кешируемые объекты часто меняются (запрашиваются только для редактирования, например, SELECT и UPDATE будет поровну), кеш только ухудшит производительность. Проблему UPDATE это тоже не решает. Одно сохранение объекта выливается в [количество полей + 1] запросов в транзакции, вместо одного.

Ага, гемморой

A>Подобные проблемы, я считаю разумным решать через ХП, скрывающие структуру БД. Пользователь БД не знает одна у него таблица хранит сущность (в данном случае User) или она разбросана по нескольким таблицам. Более того, при изменении переписывается ХП, но не тот, кто её использует. Переносить это выше, в DAL, не разумно так как у нас особенности структуры БД теперь светятся в двух разных местах (на SQL — схема, на Java/C#/C++ — запросы) на двух разных языках и это надо регулярно синхронизировать.

А я вот не согласен. О каком пользователе БД вы говорите? У меня бизнес-логика вообще не знает, повторяю ВООБЩЕ, об особенностях хранении объектов в базе, о запросах, это скрыто соответствующими классами DAL (в частности DAO) и маппингом который указывается декларативно! Какая длина поля в базе, в какую таблицу заносить и т.д. все это скрыто. Ваше решение привязывает вас к конкретному поставщику БД, а я свою программу могу использовать с MySQL, PostgreSQL (суперская вещь), Oracle и т.д. В 10% случаев надо что-то подкрутить в DAL и все. Вот не устроил меня MySQL в котором двуфазный коммит отсутствует, я с него переехал на постгре, и почти ничего подкручивать не надо.

A>Иногда, на простых данных ORM действительно выдают что-то близкое идеалу. Часто, на не очень сложных данных, ORM выдают что-то относительно приемлемое. Но стоит продумать схему БД как следует, чтобы это была действительно хорошая схема, а не тормоз или монолит и всё что нагенерировали ORM приходится выкидывать. Вот потому я и считаю, что действительно перспективным и правильным является отображать Relational в Object, а не наоборот как сейчас и поступают.

Up to you.

Здравствуйте, Cyberax, Вы писали:

A>>>>Не-не, это всё заплатки и хаки лишь бы не писать руками DAL.
C>>>Так этот объект — это ЧАСТЬ DAL.
A>>Я думал, что User в данном случае BO.

C>Нет, это часть слоя доступа к данным

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

Тут бы я поспорил конечно, но спор будет терминологическим

. Все же объекты Domain Model это равноправная часть бизнес-логики, ведь вы не можете в сервисных (бизнес) методах избавиться от того же User и пр. Т.е. по мне так бизнес-логика не только какие-то голые функции, но и передача информации, flow.

A>>BO — часть DAL звучит как-то странно. BO возвращается DAL, но от DAL зависеть не должен.
C>А у нас нет зависимости UserProperties от DAL. Для клиентов класса методы setName/getName работают абсолютно прозрачно, а то что они используют для хранения внутреннюю карту — так это личное дело объекта.

C>Ну и как я сказал — даже от этого можно избавится, но придется писать дополнительный код.

Можно избавиться от аннотаций и переписать на XML, тогда User станет с виду обычным POJO. И adontz уже не сможет придраться

Жаль hibernate, jpa не позволяют аннотировать интерфейсы как Entity, было б вообще идеально с точки зрения разделения ответственности, но это принципиальная проблема.

Здравствуйте, adontz, Вы писали:

A>Подобные проблемы, я считаю разумным решать через ХП, скрывающие структуру БД.

ХП не лучший выбор в данном случае. Лучше такие вещи решать через view.

... << RSDN@Home 1.2.0 alpha rev. 771>>

Здравствуйте, adontz, Вы писали:
A>Ну вот изменилось ТЗ (добавилась/изменилась функциональность) и кто-то (скажем, Архитектор, хотя не суть) добавил. Вот хороший был пример с секретным вопросом для восстановления доступа. В моей схеме БД вообще не затрагивается, даже DAL может не затрагиватся если оперирует только с коллекцией Dictionary<string, string> Properties. А так, пришлось бы столбец добавлять.
Идея правильна, в реализации не уверен.
Я имел опыт с системами, построенными подобным образом. Традиционно считается, что схему данных менять тяжелее, чем сами данные.
Однако это далеко не всегда так; кроме того, "добавление колонок" далеко не всегда сводится только к полям в UI. Как только начнет появляться какая-то бизнес-логика вокруг этих полей, например foreign key или запросы по их содержимому, начинаются проблемы. Как на уровне БД так и на уровне маппинга. По сравнению с этими трудностями alter table add column покажется детским лепетом.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Cyberax, Вы писали:
C>В Java такое есть — недавно всю крутость ощутил. В .NET/C++ тоже ничего не мешает добавить.
Расскажи поподробнее — если мы такую штуку для дотнета напишем, можно будет по паре поршей купить

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, WolfHound, Вы писали:
A>>kuj думает, что T-SQL это императивный язык.
WH>Вобщето таки императивный.
Совершенно верно. Операторы T-SQL декларативны, но программы на нем — императивны. Потому что мы таки управляем состоянием базы, и четко задаем последовательность этих состояний.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, kuj, Вы писали:

kuj>>>Это в том числе и о тестировании синхронизации.

В той мере, в которой ее вообще можно тестировать модульными тестами.
WH>>Интересно как ты будешь модульными тестами ловить deadlock, starvation, race condition итп?
kuj>Это не задача модульных тестов.
Выделеное твои слова?

... << RSDN@Home 1.2.0 alpha rev. 745>>

Здравствуйте, nicolas1, Вы писали:

N>Какие есть ORM для С++, пригодные для использования? В частности интересует поддерживающие sqlite.

Зачем ORM для C++? Добрался до буфера резалтсета, преобразовал его к нужной структуре и готово. ORM — это изобретение управляемых сред, потому что в них криво реализован прямой доступ к памяти.

... << RSDN@Home 1.2.0 alpha rev. 771>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Cyberax, Вы писали:
C>>В Java такое есть — недавно всю крутость ощутил. В .NET/C++ тоже ничего не мешает добавить.
S>Расскажи поподробнее — если мы такую штуку для дотнета напишем, можно будет по паре поршей купить

В это делается, как я понимаю, достаточно просто — инструментируем инструкцию monitorenter (захват лока) и некоторые методы класса Object (типа wait). В инструментации записываем в глобальную очередь точное (наносекундное) время перед входом в лок и после входа в лок.

Ну а потом эту очередь можно анализировать — определить сколько в какой момент на каждом локе было contender'ов, время ожидания и т.п.

Здравствуйте, Trean, Вы писали:

A>>>BO — часть DAL звучит как-то странно. BO возвращается DAL, но от DAL зависеть не должен.
C>>А у нас нет зависимости UserProperties от DAL. Для клиентов класса методы setName/getName работают абсолютно прозрачно, а то что они используют для хранения внутреннюю карту — так это личное дело объекта.
C>>Ну и как я сказал — даже от этого можно избавится, но придется писать дополнительный код.
T>Можно избавиться от аннотаций и переписать на XML, тогда User станет с виду обычным POJO. И adontz уже не сможет придраться

Ну я так обычно и делаю. Не нравятся мне аннотации — код превращается в сплошную мешанину.

Здравствуйте, kuj, Вы писали:
kuj>А так примерно и получается. Зато BLL это именно BLL, который ничего о других слоях не знает и знать не хочет.
Это тупик. Мы сейчас находимся в таком, я в отчаянии бью челом об стену. Считаю подобную практику порочной, по крайней мере для языка читающих запросов.

A>>Постепенно приходим к осознанию необходимости Query object.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Это тупик. Мы сейчас находимся в таком, я в отчаянии бью челом об стену. Считаю подобную практику порочной, по крайней мере для языка читающих запросов.

Терпи, браток, скоро грянет линк.

... << RSDN@Home 1.2.0 alpha rev. 771>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, kuj, Вы писали:
kuj>>А так примерно и получается. Зато BLL это именно BLL, который ничего о других слоях не знает и знать не хочет.
S>Это тупик. Мы сейчас находимся в таком, я в отчаянии бью челом об стену. Считаю подобную практику порочной, по крайней мере для языка читающих запросов.

Разъясните подробнее пожалуйста.

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

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, IT, Вы писали:

N>>Какие есть ORM для С++, пригодные для использования? В частности интересует поддерживающие sqlite.
IT>Зачем ORM для C++? Добрался до буфера резалтсета, преобразовал его к нужной структуре и готово. ORM — это изобретение управляемых сред, потому что в них криво реализован прямой доступ к памяти.
Уже есть такое

А если просто отображать объекты напрямую на дисковые файлы — то вообще...

Здравствуйте, Cyberax, Вы писали:
C>Ну а потом эту очередь можно анализировать — определить сколько в какой момент на каждом локе было contender'ов, время ожидания и т.п.
А, ну то есть фактически профилируем время ожидания на различных объектах.
Там еще по-хорошему невредно следить за тем, кто лок в это время держит.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

C>>Ну а потом эту очередь можно анализировать — определить сколько в какой момент на каждом локе было contender'ов, время ожидания и т.п.
S>А, ну то есть фактически профилируем время ожидания на различных объектах.
S>Там еще по-хорошему невредно следить за тем, кто лок в это время держит.
Так это тоже можно из этой очереди вычислить, если я не ошибаюсь. Естественно, в очередь также надо записывать идентификатор лока и потока.

Определение "кто держит" имеет смысл, если это сделать работающим в режиме "online" в отладчике. В принципе, это тоже не очень сложно.

Вообще, можно действительно продукт такой сделать — если интересно можно в почте продолжить.

Здравствуйте, Cyberax, Вы писали:

C>Уже есть такое

А если просто отображать объекты напрямую на дисковые файлы — то вообще...

И не говори. Лет 10 назад я писал свою специализированную БД и именно так и делал на map-файлах. Крутяк!

... << RSDN@Home 1.2.0 alpha rev. 771>>

Здравствуйте, kuj, Вы писали:
A>>Плюс коллекции хибернета нарушают PI.
kuj>Не совсем понял. Разъясните пожалуйста.

Very Important Note: If the <key> column of a <one-to-many> association is declared NOT NULL, NHibernate may cause constraint violations when it creates or updates the association. To prevent this problem, you must use a bidirectional association with the many valued end (the set or bag) marked as inverse="true". See the discussion of bidirectional associations later in this chapter.

Вынуждены использовать коллекции хибернета вместо стандартных.

Здравствуйте, Aviator, Вы писали:

A>>>Плюс коллекции хибернета нарушают PI.
kuj>>Не совсем понял. Разъясните пожалуйста.

A>Very Important Note: If the <key> column of a <one-to-many> association is declared NOT NULL, NHibernate may cause constraint violations when it creates or updates the association. To prevent this problem, you must use a bidirectional association with the many valued end (the set or bag) marked as inverse="true". See the discussion of bidirectional associations later in this chapter.
A>

A>Вынуждены использовать коллекции хибернета вместо стандартных.

Э-э, а чем это мешает BLL? Ведь работаем-то все-равно через интерфейсы (IList, ICollections, etc). Или Вы не об этом, говоря, что нарушается PI?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>Разъясните подробнее пожалуйста.
Разъясняю подробнее: в каждой версии продукта мы вынуждены добавлять новые методы в API только для того, чтобы обработать новый класс запросов. Типа было GetUserByName(), теперь надо еще и GetUserByID(), FindUsersWhereNameLike(string namePart). А потом нужно еще и FindUsersWhereNameLike(string namePart, int pageSize, int pageNum, FieldName orderBy).
И это всё — практически без изменений модели данных; просто народу нужны разные view на наши данные.
Альтернатива — заставлять всех делать GetAllUsers() и потом самостоятельно сортировать/фильтровать — нереалистична в enterprize инсталляциях, где этих пользователей под сотню тыщ.
Получается какой-то экспоненциальный взрыв интерфейса сервиса на пустом месте.
Query Object в этом смысле — спасение. Но с ним нужен глаз да глаз, т.к. теряется преимущество compile-time валидации.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Получается какой-то экспоненциальный взрыв интерфейса сервиса на пустом месте.
S>Query Object в этом смысле — спасение. Но с ним нужен глаз да глаз, т.к. теряется преимущество compile-time валидации.
А если механически разбить все эти GetUsersByBlah на несколько сервисов?

bnk>>>Это.. Как там... "Занятие включает рассказ, показ, тренировку", ага
bnk>>>

300 постов и НИ 1-го конкретного полного ответа на мои вопросы.

не считаю, что у меня более высокий опыт, пишу как понял из книг (сам просто интересуюсь темой)

по слоям:
1) Domain Model = Business Logic Layer = Model Layer

namespace Root.DomainLayer
{
    // IDomainObject - layer supertype - держит общее поведение всех классов слоя
    class Order : IDomainObject
    {

        // поля
        ...

        IDictionary<Product, int> Items
        {
            get
            ...
            set
            {
                // проверка состояния заказа и присваивание - валидация
                ...
            }
        }

        Money Price
        {
            get
            {
                // расчёт цены - бизнес-логика
                ...
            }
        }
        // методы доступа к данным НЕ здесь!!
        // остальное - binding, вызовы за пределы слоя - тоже не здесь.
    }
}

2) интерфейс — Presentation layer

namespace Root.UI
{
    // это одно из решений - вроде бы по паттерну Model-View-Controller
    class ShoppingCartForm : Form
    {
        //используется data binding свойств объекта к контролам.
        private Customer client;
        // если нужно куда-то вставить дополнительный код для биндинга, можно к domain object применить паттерн Extension Object/Interface

        private CustomerController controller;

        ...
        private btnOrder_Click(...)
        {
            controller.PlaceOrder(client);
        }
    }

    class CustomerController
    {
        // возможна ссылка на Customer здесь, а не в форме, тогда это кажется Model-View-Presenter

        void PlaceOrder(Customer client)
        {
            Order newOrder = ApplicationController.OrderService.Place(client);
            // как-то открыть форму заказа с newOrder, хотя за оптимальность решения не уверен
            ...
        }
        
    }
}

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

3) Application Layer = Service Layer

namespace Root.ApplicationLayer
{
    // Service Locator, для той же цели можно использовать какойнибудь контейнер
    class ApplicationController
    {
        private IOrderProcessingService orderService;

        // паттерн singleton
        private static ApplicationController instance;
        private ApplicationController() { }

        static void Configure()
        {
            instance = new ApplicationController();
            // не знаю как
            ...
        }

        static IOrderProcessingService OrderService
        {
            get
            {
                return instance.orderService;
            }
        }
    }


    class OrderProcessingServiceImpl : IOrderProcessingService
    {
        IManager<Order> mapper = null;
        ...

        Order Place(Customer client)
        {
            // здесь могут быть внешние вызовы, транзакции, вызовы бизнес-логики и обращения к DAL
            Order order = new Order(client.Cart);
            mapper.Save(order);
            client.Orders.Add(order);
            return order;
        }

        // остальные методы обработки заказов
        ...
    }

    // возможно этот класс в отдельной сборке Launcher
    class Application
    {
        void Main(String[] args)
        {
            ApplicationController.Configure();
            // сам последннее време пользую фреймворки Eclipse RCP и MS Composite UI Application Block с SCSF, так что если без них, то хождение по Use Case'ам (то есть упавляемый показ форм/view) придумывайте сами
            ....
        }
    }
}

4) DAL — паттерн Data Mapper

namespace Root.DataAccessLayer
{
    // здесь методы доступа к данным
    class Manager<TDomainObject> where TDomainObject : IDomainObject
    {
        // Query - не знаю как он в Hibernate называется
        public Collection<TDomainObject> List(Query criteria)
        {
            // это тоже типа Hibernate, просто давно не ползовался забыл названия
            session.Select(...
        }

        public void Save(TDomainObject data)
        {
            ...
        }

        public bool Delete(ID arg)
        {
            ...
        }
    }
}

основано на материалах martinfowler.com

критикуйте

Здравствуйте, IT, Вы писали:

IT>И в чём проблема добавить ещё одно поле в таблицу?

Проблема существенная. Во-первых, это добавление цепной реакцией прокатывается по всем SQL запросам. Во-вторых, столбец надо добавить во множестве мест, то есть приходиться делать уже не просто инсталляции, а апдейтеры зовущие ALTER TABLE и тестировать не только инсталляцию продукта, но и апдейтеры на всех комбинациях версий продукта. Это нелинейно увеличивает объём тестирования.

Здравствуйте, Trean, Вы писали:

T>Ха-ха, так в ряде случаев такая структура — известный анти-паттерн, есть даже для нее название, но я к сожалению не могу припомнить его. Структура запросов с джойнами, агрегатами настолько усложняется, что ну его нафиг. Для системы к которой предъявляются требования по выскокой производительности — такая денормализованная структура bad practice. Вот для CMS какой-нибудь — нормально, так сделано в Alfresco CMS (кстати тоже через Hibernate).

Ты не понял, видимо. Доступ ко всем UserProperties одинаковый. То есть нет запроса вида
UPDATE UserProperties SET value='{0}' WHERE name='FirstName'
есть только запросы вида
UPDATE UserProperties SET value='{0}' WHERE name='{1}'

T>А я вот не согласен. О каком пользователе БД вы говорите? У меня бизнес-логика вообще не знает, повторяю ВООБЩЕ, об особенностях хранении объектов в базе, о запросах, это скрыто соответствующими классами DAL (в частности DAO) и маппингом который указывается декларативно! Какая длина поля в базе, в какую таблицу заносить и т.д. все это скрыто. Ваше решение привязывает вас к конкретному поставщику БД, а я свою программу могу использовать с MySQL, PostgreSQL (суперская вещь), Oracle и т.д. В 10% случаев надо что-то подкрутить в DAL и все. Вот не устроил меня MySQL в котором двуфазный коммит отсутствует, я с него переехал на постгре, и почти ничего подкручивать не надо.

Не привязывает, всё специфика остаётся в БД, наружу торчит только ХП. Даже DAL при переходе на другую БД не особо переписывается.

Здравствуйте, Sinclair, Вы писали:

S>Идея правильна, в реализации не уверен.
S>Я имел опыт с системами, построенными подобным образом. Традиционно считается, что схему данных менять тяжелее, чем сами данные.
S>Однако это далеко не всегда так; кроме того, "добавление колонок" далеко не всегда сводится только к полям в UI. Как только начнет появляться какая-то бизнес-логика вокруг этих полей, например foreign key или запросы по их содержимому, начинаются проблемы. Как на уровне БД так и на уровне маппинга. По сравнению с этими трудностями alter table add column покажется детским лепетом.

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

Здравствуйте, IT, Вы писали:

A>>Подобные проблемы, я считаю разумным решать через ХП, скрывающие структуру БД.
IT>ХП не лучший выбор в данном случае. Лучше такие вещи решать через view.

Я как-то не соображу чем View в поддержке проще ХП если и там и тут запрос.

Здравствуйте, adontz, Вы писали:

IT>>И в чём проблема добавить ещё одно поле в таблицу?

A>Проблема существенная. Во-первых, это добавление цепной реакцией прокатывается по всем SQL запросам. Во-вторых, столбец надо добавить во множестве мест, то есть приходиться делать уже не просто инсталляции, а апдейтеры зовущие ALTER TABLE и тестировать не только инсталляцию продукта, но и апдейтеры на всех комбинациях версий продукта. Это нелинейно увеличивает объём тестирования.

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

... << RSDN@Home 1.2.0 alpha rev. 771>>

Здравствуйте, adontz, Вы писали:

A>Я как-то не соображу чем View в поддержке проще ХП если и там и тут запрос.

1. View можно джоинить с другими таблицами.
2. ХП не имеет формальной структуры результата.

... << RSDN@Home 1.2.0 alpha rev. 771>>

Здравствуйте, IT, Вы писали:

IT>>>И в чём проблема добавить ещё одно поле в таблицу?

A>>Проблема существенная. Во-первых, это добавление цепной реакцией прокатывается по всем SQL запросам. Во-вторых, столбец надо добавить во множестве мест, то есть приходиться делать уже не просто инсталляции, а апдейтеры зовущие ALTER TABLE и тестировать не только инсталляцию продукта, но и апдейтеры на всех комбинациях версий продукта. Это нелинейно увеличивает объём тестирования.

IT>Думаю, тогда тебе лучше всего создать одну таблицу, где будет тип сушности, ID, имя поля и значение. Проблем вообще никаких не будет.

Кстати, IMHO, это было бы весьма здорово, но на больших объемах данных это к сожалению будет крайне неэффективно...
А так для небольших объемов — самое оно. Идеология "ID, имя поля и значение" — IMHO вообще рульный подход.

Обеспечивает замечательную гибкость при минимальном количестве гемороя (при добавлении новых "фич").

Но если уж отказываемся от такого подхода и делаем в несколько связанных таблиц то внешние
ключи хранить в виде "имя — значение" — это конечно будет полный бред,
для них будет проще (и правильнее) добавлять колонку..

Здравствуйте, bnk, Вы писали:

IT>>Думаю, тогда тебе лучше всего создать одну таблицу, где будет тип сушности, ID, имя поля и значение. Проблем вообще никаких не будет.

bnk>Кстати, IMHO, это было бы весьма здорово

Берёшь свой любой запрос в котором хотя бы три таблицы и десяток полей и переписываешь его по такой схеме. Потом смотришь здорово это или нет.

... << RSDN@Home 1.2.0 alpha rev. 771>>

Здравствуйте, IT, Вы писали:

IT>>>Думаю, тогда тебе лучше всего создать одну таблицу, где будет тип сушности, ID, имя поля и значение. Проблем вообще никаких не будет.

bnk>>Кстати, IMHO, это было бы весьма здорово

IT>Берёшь свой любой запрос в котором хотя бы три таблицы и десяток полей и переписываешь его по такой схеме. Потом смотришь здорово это или нет.

Ну дак мы же говорим про ОДНУ таблицу.

Понятно что для нескольких это (в лоб) не сработает.
Я же специально оговорился про внешние ключи и т.п.

Идея в том что вот это:

| ID | NAME | VALUE |
---------------------
| 1  | A    | X     |
| 1  | B    | X     |
| 2  | A    | Y     |
| 2  | B    | Y     |

"лучше" (гибче, "удобнее в апгрейде") чем вот это:

| ID | A | B |
--------------
| 1  | X | X |
| 2  | Y | Y |

Хотя очевидно тормознутее.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Trean, Вы писали:

T>>Ха-ха, так в ряде случаев такая структура — известный анти-паттерн, есть даже для нее название, но я к сожалению не могу припомнить его. Структура запросов с джойнами, агрегатами настолько усложняется, что ну его нафиг. Для системы к которой предъявляются требования по выскокой производительности — такая денормализованная структура bad practice. Вот для CMS какой-нибудь — нормально, так сделано в Alfresco CMS (кстати тоже через Hibernate).

A>Ты не понял, видимо. Доступ ко всем UserProperties одинаковый. То есть нет запроса вида
A>UPDATE UserProperties SET value='{0}' WHERE name='FirstName'
A>есть только запросы вида
A>UPDATE UserProperties SET value='{0}' WHERE name='{1}'

Я не про это. Сколько надо update statements, чтобы изменить разом несколько свойств пользователя? Или как будет выглядеть запрос поиска пользователя, имеющего заданные свойства, например, имя, фамилию, телефон.

T>>А я вот не согласен. О каком пользователе БД вы говорите? У меня бизнес-логика вообще не знает, повторяю ВООБЩЕ, об особенностях хранении объектов в базе, о запросах, это скрыто соответствующими классами DAL (в частности DAO) и маппингом который указывается декларативно! Какая длина поля в базе, в какую таблицу заносить и т.д. все это скрыто. Ваше решение привязывает вас к конкретному поставщику БД, а я свою программу могу использовать с MySQL, PostgreSQL (суперская вещь), Oracle и т.д. В 10% случаев надо что-то подкрутить в DAL и все. Вот не устроил меня MySQL в котором двуфазный коммит отсутствует, я с него переехал на постгре, и почти ничего подкручивать не надо.

A>Не привязывает, всё специфика остаётся в БД, наружу торчит только ХП. Даже DAL при переходе на другую БД не особо переписывается.

А что синтаксис хранимок oracle и mssql настолько одинаков? Кроме того, как реализовать запросы с переменным кол-вом параметров через ХП? Прописывать все возможные варианты?

Последний раз (года так 3 назад), когда я интересовался как это сделать в MSSQl в форумах было написано, что сделать это можно только через грязный хак с массивами, и врядли это портабельное решение. Избежать привязки клиента к конкретной базе оградившись лишь забором из ХП — невозможно. View, как тут выше писали, вот это действительно хорошее решение в ряде случаев, особо что касается Read-Only View.

Когда-нибудь у меня дойдут руки написать небольшой тестик и сравнить скорость выполнения бизнес-логики в ХП и скажем в C или Java. Человек долго работавший с MSSQL, сказал, что на удивление, тот же код переписанный на С оказался быстрее эквивалентного кода на ХП даже с footprint вызванным необходимостью передавать данные клиенту БД на обработку.

Здравствуйте, bnk, Вы писали:

bnk>Хотя очевидно тормознутее.

Кстати далеко не факт что будет существенная разница. Кластерные индексы решают.

Здравствуйте, Trean, Вы писали:

T>Я не про это. Сколько надо update statements, чтобы изменить разом несколько свойств пользователя? Или как будет выглядеть запрос поиска пользователя, имеющего заданные свойства, например, имя, фамилию, телефон.

При таком подходе обычно UPDATE, заменяется на INSERT или DELETE+INSERT. Количество запросов порядка количества изменившихся полей. Для того же User при изменении фамилии можно писать только фамилию и не городить для этого отдельный запрос. Для объектов изменяющихся полностью выгоды никакой, сплошные убытки. Эффективно искать тоже не выйдет. Хотя и со столбцами эффективно искать не выйдет, на все столбцы индексы не повесишь.

Я вообще это всё предлагал как пример схемы БД поддерживающей некоторые расширения бизнес-логики без переделки схемы БД, а не как универсальное средство. Критика верная, но не совсем в кассу.

T>А что синтаксис хранимок oracle и mssql настолько одинаков?

Синтаксис вызова хранимок из ADO достаточно одинаков. А при переезде с Oracle на MSSQL и так придётся много чего переписать.

T>Кроме того, как реализовать запросы с переменным кол-вом параметров через ХП?

Это зачем тебе такое на уровне БД? Мне приходит в голову только поиск, но если мы говорим о чётком поиске (user по id) то никакого переменного числа параметров нет, а если о нечётком (помню 3ю буква в фамилии и 5ую в имени), то это не для уровня БД задача.

T>Когда-нибудь у меня дойдут руки написать небольшой тестик и сравнить скорость выполнения бизнес-логики в ХП и скажем в C или Java.

Никто бизнес-логику в ХП переносить и не предлагал.

Здравствуйте, Суслик, Вы писали:

С>Здравствуйте, Kazna4ey, Вы писали:

С>10000 строк кода? Да это не много. Ну в том смысле, что 10000 строк можно полностью перелопатить и не трястись от страха, что что-то забыл.

Да уж. Помню в небольшом проектике где таблиц 40 было, DAO класс (он был почему то один) было больше 5000 строк.
Правда там был низкоуровневый JDBC

Здравствуйте, adontz, Вы писали:

IT>>И в чём проблема добавить ещё одно поле в таблицу?

A>Проблема существенная. Во-первых, это добавление цепной реакцией прокатывается по всем SQL запросам. Во-вторых, столбец надо добавить во множестве мест, то есть приходиться делать уже не просто инсталляции, а апдейтеры зовущие ALTER TABLE и тестировать не только инсталляцию продукта, но и апдейтеры на всех комбинациях версий продукта. Это нелинейно увеличивает объём тестирования.

И Вы все еще рекомендуете использовать ХП вместо ORM?

Ежики плакали, но продолжали жрать кактус.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kejroot, Вы писали:

K>основано на материалах martinfowler.com

K>критикуйте

В целом хороший ответ, только Вас сейчас закидают гнилыми помидорами за применение синглтона.

Очень рекомендую Castle Windsor (или MicroKernel) для уменьшения зависимостей.

http://www.castleproject.org/container/index.html

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

A>>Проблема существенная. Во-первых, это добавление цепной реакцией прокатывается по всем SQL запросам. Во-вторых, столбец надо добавить во множестве мест, то есть приходиться делать уже не просто инсталляции, а апдейтеры зовущие ALTER TABLE и тестировать не только инсталляцию продукта, но и апдейтеры на всех комбинациях версий продукта. Это нелинейно увеличивает объём тестирования.
kuj>И Вы все еще рекомендуете использовать ХП вместо ORM?

Коррекция SQL запросов по сранению с тестированеим инсталляции в режиме обновления сущие пустяки. Никакие ORM не потмогу написать корректный апдейтер.
У ХП совсем другие преимущества, я их уже указывал. Быть слепым личное дело каждого.

Здравствуйте, IT, Вы писали:

IT>1. View можно джоинить с другими таблицами.
IT>2. ХП не имеет формальной структуры результата.

Я вообще-то про поддержку спрашивал, а не про использование.

Здравствуйте, adontz, Вы писали:

A>>>Проблема существенная. Во-первых, это добавление цепной реакцией прокатывается по всем SQL запросам. Во-вторых, столбец надо добавить во множестве мест, то есть приходиться делать уже не просто инсталляции, а апдейтеры зовущие ALTER TABLE и тестировать не только инсталляцию продукта, но и апдейтеры на всех комбинациях версий продукта. Это нелинейно увеличивает объём тестирования.
kuj>>И Вы все еще рекомендуете использовать ХП вместо ORM?

A>Коррекция SQL запросов
При чем тут запросы, если речь о процедурах. Вы, конечно же, ничего не знаете о синтаксисе того же PL/SQL и как значительно он отличается от T-SQL? PL/SQL значительно мощнее T-SQL, поэтому "downgrade" на T-SQL зачастую задача далеко не тривиальная.

A>по сранению с тестированеим инсталляции в режиме обновления сущие пустяки. Никакие ORM не потмогу написать корректный апдейтер.
Плохому танцору яйца мешают.

A>У ХП совсем другие преимущества, я их уже указывал.
Где?
тезис 1: хп хорошо потому, что "использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными" — false
тезис 2: хп хорошо потому, что "ХП позволяют держать в БД не только данные, но и код управления данными, обеспечивая их целостность (группировку запросов в транзакции и т.п.) на уровне хранения." — запросы в транзакции и с использованием ORM объединяются прекрасно и ORM дают даже более мощную функциональность по управлению транзакциями — false
тезис 3: хп хорошо потому, что "ХП напротив проще поддерживать" — нетестируемые, нечитабельные, почти не поддающиеся рефакторингу, куда более сильно привязанные к СУБД и конкретной схеме — false

A>Быть слепым личное дело каждого.
Совершенно верно. Быть слепым это Ваше личное дело. Только не надо пытаться навязывать другим плоды своего ограниченного мышление, не обремененного знаниями современных технологий в области архитектуры enterprise-приложений и БД.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

A>>Коррекция SQL запросов
kuj>При чем тут запросы, если речь о процедурах. Вы, конечно же, ничего не знаете о синтаксисе того же PL/SQL и как значительно он отличается от T-SQL? PL/SQL значительно мощнее T-SQL, поэтому "downgrade" на T-SQL зачастую задача далеко не тривиальная.

Осталось только выяснить зачем переходить с PL/SQL на T-SQL при добавлении столбца в таблицу. kuj вы вообще клинический идиот?

A>>по сранению с тестированеим инсталляции в режиме обновления сущие пустяки. Никакие ORM не потмогу написать корректный апдейтер.
kuj>Плохому танцору яйца мешают.

Ещё один мегагениальный комментарий от человека который никогда не занимался поддержкой инсталляций.

kuj>тезис 1: хп хорошо потому, что "использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными" — false

true. И Синклер тебе даже дал ссылку на инструментарий.

kuj>тезис 2: хп хорошо потому, что "ХП позволяют держать в БД не только данные, но и код управления данными, обеспечивая их целостность (группировку запросов в транзакции и т.п.) на уровне хранения." — запросы в транзакции и с использованием ORM объединяются прекрасно и ORM дают даже более мощную функциональность по управлению транзакциями — false

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

kuj>тезис 3: хп хорошо потому, что "ХП напротив проще поддерживать" — нетестируемые, нечитабельные, почти не поддающиеся рефакторингу, куда более сильно привязанные к СУБД и конкретной схеме — false

Тебе тут несколько человек написало, что у них есть проекты на ХП и они не страдают по этому поводу.

kuj>Совершенно верно. Быть слепым это Ваше личное дело. Только не надо пытаться навязывать другим плоды своего ограниченного мышление, не обремененного знаниями современных технологий в области архитектуры enterprise-приложений и БД.

У меня по крайне мере есть мышление, а твои сообщения либо бессмысленны, либо противоречивы.

Здравствуйте, Cyberax, Вы писали:
C>А если механически разбить все эти GetUsersByBlah на несколько сервисов?
А смысл?

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Sinclair, Вы писали:

S>>Идея правильна, в реализации не уверен.
S>>Я имел опыт с системами, построенными подобным образом. Традиционно считается, что схему данных менять тяжелее, чем сами данные.
S>>Однако это далеко не всегда так; кроме того, "добавление колонок" далеко не всегда сводится только к полям в UI. Как только начнет появляться какая-то бизнес-логика вокруг этих полей, например foreign key или запросы по их содержимому, начинаются проблемы. Как на уровне БД так и на уровне маппинга. По сравнению с этими трудностями alter table add column покажется детским лепетом.

A>Ну вообще-то из примера вроде было видно, что группируются таким образом только то, над чем проводятся однотипные операции. Login и Password я не вынес. Во-первых, это ударит по производительности, во-вторых, с ними проводится совсем другой набор операций.
Я это веду к тому, что раз уж такие "резиновые" поля так отличаются от "основных", то может иметь смысл отразить это и на уровне апп.сервера. Т.е. так и добавить в Person свойство CustomProperties типа Dictionary<string, object>. Тогда добавление нового свойста не затронет не только БД, но даже и код перекомпилировать не придется!

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Cyberax, Вы писали:
C>>А если механически разбить все эти GetUsersByBlah на несколько сервисов?
S>А смысл?
Просто сгруппировать по определенным признакам, для удобства редактирования. Нет ничего плохого в разрастании количества DAO-методов — это просто значит, что у вас много логики.

Здравствуйте, Cyberax, Вы писали:
C>Просто сгруппировать по определенным признакам, для удобства редактирования.
Для удобства редактирования чего?
C>Нет ничего плохого в разрастании количества DAO-методов — это просто значит, что у вас много логики.
Имхо, это иллюзия. Я наглядно вижу разрастание количества DAO методов на пустом месте, и неэффективное использование как ресурсов сервера, так и канала при передаче избыточных данных.

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

C update-методами есть другая аналогичная проблема: поскольку нет способа объединить несколько методов в транзакцию, то нам приходится публиковать методы для различных популярных комбинаций.
Например, есть методы CreateUser, CreateSite, AssignSiteToUser. Эти методы нужны, т.к. вызываются в некоторых бизнес-сценариях. Теперь обнаруживается сценарий, при котором нужно сразу создать пользователя, сайт, и присвоить сайт пользователю. Проблема в том, что если какое-то из действий не пройдет, то нужно откатывать всё. Конечно, можно сделать с клиента цепочку try с обратными действиями в catch:

user=CreateUser(...);
try
{
  site = CreateSite(...);
    try
    {
      AssignSiteToUser(site, user);
    }
    catch
    {
      DeleteSite(site);
        throw;
    }
}
catch
{
  DeleteUser();
    throw;
}

Но это-ненадежная схема, т.к. если в процессе порвется коннект, то Delete*() вызвать не удастся у нас так и останется мусор в сервере.
Поэтому мы делаем метод CreateUserWithSite с совершенно тривиальной реализацией.

В итоге, я начинаю думать, что SQL — значительно более хороший протокол клиент-серверного взаимодействия, чем, к примеру, SOAP. Потому, что там ни одной из этих проблем нет: мы можем указывать произвольные предикаты для отбора и сортировки записей, а не только те, которые предусмотрел разработчик БД; мы можем запрашивать только те поля, которые нам нужны; мы можем управлять атомарностью действий, оборачивая батч в явную транзакцию.

у SQL, конечно же, есть свои недостатки. Но, имхо, невредно было бы придумать схему с преимуществами обоих подходов.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, Aviator, Вы писали:

A>>>>Плюс коллекции хибернета нарушают PI.
kuj>>>Не совсем понял. Разъясните пожалуйста.

A>>Very Important Note: If the <key> column of a <one-to-many> association is declared NOT NULL, NHibernate may cause constraint violations when it creates or updates the association. To prevent this problem, you must use a bidirectional association with the many valued end (the set or bag) marked as inverse="true". See the discussion of bidirectional associations later in this chapter.
A>>

A>>Вынуждены использовать коллекции хибернета вместо стандартных.

kuj>Э-э, а чем это мешает BLL? Ведь работаем-то все-равно через интерфейсы (IList, ICollections, etc). Или Вы не об этом, говоря, что нарушается PI?
Вынуждены использовать конкретную реализацию коллекции, навязанную персистентным слоем, вместо того, что бы выбирать реализацию в соответсвии с требованиями BL.

Здравствуйте, Sinclair, Вы писали:

C>>Нет ничего плохого в разрастании количества DAO-методов — это просто значит, что у вас много логики.
S>Имхо, это иллюзия. Я наглядно вижу разрастание количества DAO методов на пустом месте, и неэффективное использование как ресурсов сервера, так и канала при передаче избыточных данных.
S>Я бы хотел избежать необходимости менять публичный контракт сервиса всякий раз, как один из клиентов немножко переделает UI.
У меня DAO-аксессоры находятся в статических методах helper-классов. Так что никаких проблем.

S>Например, есть методы CreateUser, CreateSite, AssignSiteToUser. Эти методы нужны, т.к. вызываются в некоторых бизнес-сценариях. Теперь обнаруживается сценарий, при котором нужно сразу создать пользователя, сайт, и присвоить сайт пользователю. Проблема в том, что если какое-то из действий не пройдет, то нужно откатывать всё. S>Поэтому мы делаем метод CreateUserWithSite с совершенно тривиальной реализацией.
Нда... Неудивительно тогда, что головой об стенку стучите.

Есть более надежное решение — явно передавать транзакционный контекст в DAO-методы. Например, у меня оно сделано так:

public class ShiftLocationHelper
{
   public List<Shift> getShiftsNearestToLocation(Session sess, Location loc)
   {
       return sess.createQuery("...").list();
   }
};

Сессия, которую я явно передаю в качестве параметра, связана с транзакционным контекстом. Если не хочется передавать транзакционный контекст явно — храните его во thread-local переменной (и ругайтесь в аксессорах, если нет текущего контекста).

Причем это все очень хорошо сочетается с AOP. Скажем, у меня транзакции управляются автомагически (использую Spring):

@Transactional(readOnly=true)
public class SomeService
{
    //Будет "впрыснута" контейнером, с автоматическим распространением транзакционного контекста.
    private Session session;

    public void doSomething()
    {
        //Здесь у нас _обязательно_ будет транзакционный контекст.
    }
    
    @Transactional(propagation=REQUIRES_NEW)
    public void doSomethingBad()
    {
        //Здесь у нас тоже будет транзакция, но она будет создана при входе в 
        //метод и закоммичена/откачена при выходе из метода. На длительность метода
        //предыдущая транзакция (если она есть) приостанавливается.
    }
    //И т.п. Еще есть Supports/Never/Nested/...
}
//XML-файл с настройками пропускаю.

//Используем примерно так:
UserTransactionManager utm=(UserTransactionManager)factory.getBean("userTransactionManager");
SomeService src=(SomeService)factory.getBean("someServiceName");

//Это совсем ручное управление транзакциями - обычно его можно тоже автоматизировать.
utm.begin();
try
{
  src.doSomething(param1);
  src.doSomething(param2);
  utm.commit();
} catch(Throwable t)
{
  utm.rollback();
}

В результате, использовать такое ОЧЕНЬ удобно. Про проблемы с транзакциями я даже уже и думать забыл.

S>В итоге, я начинаю думать, что SQL — значительно более хороший протокол клиент-серверного взаимодействия, чем, к примеру, SOAP.
SOAP — это вообще маразм. Он сейчас повторяет всю историю CORBA.

S>Потому, что там ни одной из этих проблем нет: мы можем указывать произвольные предикаты для отбора и сортировки записей, а не только те, которые предусмотрел разработчик БД; мы можем запрашивать только те поля, которые нам нужны; мы можем управлять атомарностью действий, оборачивая батч в явную транзакцию.
S>у SQL, конечно же, есть свои недостатки. Но, имхо, невредно было бы придумать схему с преимуществами обоих подходов.
Может вам стоит на Spring+Hibernate в Java посмотреть?

Там множество этих проблем уже решено.

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

Здравствуйте, Cyberax, Вы писали:
S>>Я бы хотел избежать необходимости менять публичный контракт сервиса всякий раз, как один из клиентов немножко переделает UI.
C>У меня DAO-аксессоры находятся в статических методах helper-классов. Так что никаких проблем.
И что? Я не понимаю, как расположение DAO-аксессоров может помочь с сокращением dummy изменений в зависимости от пожеланий клиента.

C>Нда... Неудивительно тогда, что головой об стенку стучите.
C>Есть более надежное решение — явно передавать транзакционный контекст в DAO-методы. Например, у меня оно сделано так:
Через границу сервиса транзакционный контекст передавать нельзя. Потому, что тогда нарушится Statelessness.
S>>В итоге, я начинаю думать, что SQL — значительно более хороший протокол клиент-серверного взаимодействия, чем, к примеру, SOAP.
C>SOAP — это вообще маразм. Он сейчас повторяет всю историю CORBA.
Альтернативы? REST?
C>Может вам стоит на Spring+Hibernate в Java посмотреть?

Там множество этих проблем уже решено.
Очень я в этом сомневаюсь. Внутре апп-сервера всё и так более-менее прилично; даже BLT уже позволяет минимизировать лишний код.
Но как только мы пытаемся сделать платформенно-независимый public API, начинаются какие-то чудеса.
Мысли некоторые у меня по этому поводу есть, но пока что до реализации им, мягко говоря, далеко.

C>Вообще, я давно уже хочу нашу внутреннюю документацию по серверу приложений в нормальный вид привести и в виде статьи выложить. Всё руки не доходят...

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

C>>Нда... Неудивительно тогда, что головой об стенку стучите.
C>>Есть более надежное решение — явно передавать транзакционный контекст в DAO-методы. Например, у меня оно сделано так:
S>Через границу сервиса транзакционный контекст передавать нельзя. Потому, что тогда нарушится Statelessness.
Так решите что вам важнее — удобное управление транзакциями или statelessness. Тут одно из двух. Кстати, если напрямую использовать SQL — то это тоже уже stateful-соединения.

Кстати, еще возможное решение — отсылать на сервер блоки кода для выполнения. В Java для этого тоже есть библиотеки

S>>>В итоге, я начинаю думать, что SQL — значительно более хороший протокол клиент-серверного взаимодействия, чем, к примеру, SOAP.
C>>SOAP — это вообще маразм. Он сейчас повторяет всю историю CORBA.
S>Альтернативы? REST?
Старый добрый RPC через какой-нибудь протокол — если нужна распределенная работа. Ну и первое правило распределенного программирования — "do not distribute".

C>>Может вам стоит на Spring+Hibernate в Java посмотреть?

Там множество этих проблем уже решено.
S>Очень я в этом сомневаюсь. Внутре апп-сервера всё и так более-менее прилично; даже BLT уже позволяет минимизировать лишний код.
S>Но как только мы пытаемся сделать платформенно-независимый public API, начинаются какие-то чудеса.
S>Мысли некоторые у меня по этому поводу есть, но пока что до реализации им, мягко говоря, далеко.
У меня была та же проблема — связать друг с другом две системы, с сохранением транзакций. Делал исследование на эту тему — ничего нормального для этого нет. Есть WS-AtomicTransaction, и даже поддерживается MS и другими вендорами. Только вот на практике все получается черезчур монструозно.

В результате остановились на работе через общую базу данных и общение через транзакционный JMS (Java Messaging System).

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, kejroot, Вы писали:

K>>основано на материалах martinfowler.com

K>>критикуйте

kuj>В целом хороший ответ
Спосибо
kuj>, только Вас сейчас закидают гнилыми помидорами за применение синглтона.

а я так для упрощения написал.
вот комЕнт с отмазкой:

// Service Locator, для той же цели можно использовать какойнибудь контейнер

даже не "можно", а "лучше"

kuj>Очень рекомендую Castle Windsor (или MicroKernel) для уменьшения зависимостей.

kuj>http://www.castleproject.org/container/index.html
еще слыхал про NanoContainer (или PicoContainer),
в MS CAB используется свой ObjectBuilder.
но видимо Windsor проще

помойму вообще лучше всего делать на каком-нить каркасе, типа Spring или Eclipse RCP., там и сразу контейнер интегрирован, и большая часть работы сделана

Здравствуйте, Cyberax, Вы писали:
C>Так решите что вам важнее — удобное управление транзакциями или statelessness. Тут одно из двух.
Ничего подобного. Удобное управление транзакциями — это возможность отправить батч.
Опасно только удержание транзакции с клиентской стороны.

C> Кстати, если напрямую использовать SQL — то это тоже уже stateful-соединения.
Это если пользоваться им неаккуратно.

C>Кстати, еще возможное решение — отсылать на сервер блоки кода для выполнения.
Именно об этом я и думаю.

C>В Java для этого тоже есть библиотеки

И как их вызывать из Classic ASP или Perl?

C>Старый добрый RPC через какой-нибудь протокол — если нужна распределенная работа. Ну и первое правило распределенного программирования — "do not distribute".
А RPC-то чем поможет??? Он точно так же жестко типизирован. Отличие SOAP — только в канале.

C>У меня была та же проблема — связать друг с другом две системы, с сохранением транзакций. Делал исследование на эту тему — ничего нормального для этого нет. Есть WS-AtomicTransaction, и даже поддерживается MS и другими вендорами. Только вот на практике все получается черезчур монструозно.
Вот-вот, я о том же.
C>В результате остановились на работе через общую базу данных и общение через транзакционный JMS (Java Messaging System).

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

C>>Так решите что вам важнее — удобное управление транзакциями или statelessness. Тут одно из двух.
S>Ничего подобного. Удобное управление транзакциями — это возможность отправить батч.
S>Опасно только удержание транзакции с клиентской стороны.
Оптимистическое версирование — и никаких проблем (нуу... почти). Пусть держат сколько угодно — объекты блокироваться не будут. Всякие гадости типа исчерпания пулов из-за глючных клиентов — тоже можно при желании обрабатывать.

C>> Кстати, если напрямую использовать SQL — то это тоже уже stateful-соединения.
S>Это если пользоваться им неаккуратно.
В любом случае. SQL-соединение по своей сути имеет состояние, да хотя бы транзакционный контекст (если только не ставить автокоммит, конечно).

C>>В Java для этого тоже есть библиотеки

S>И как их вызывать из Classic ASP или Perl?
Отсылать куски скрипта на каком-нибудь языке? На сервере — посадить этот скрипт в домен с максимально обрезаными правами.

Есть, конечно, еще BPEL. Но я бы его не трогал без крайней надобности.

C>>Старый добрый RPC через какой-нибудь протокол — если нужна распределенная работа. Ну и первое правило распределенного программирования — "do not distribute".
S>А RPC-то чем поможет??? Он точно так же жестко типизирован. Отличие SOAP — только в канале.
SOAP подразумевает передачу документов и их обработку сервисами. В случае с RPC мы обычно передаем проксики для объектов на сервере и работаем с ними на клиенте. То есть, можно организовать stateful-операции сравнительно малой кровью.

Здравствуйте, Cyberax, Вы писали:
C>Оптимистическое версирование — и никаких проблем (нуу... почти). Пусть держат сколько угодно — объекты блокироваться не будут.
Ага, зато будет расти сегмент отката. Не, управление транзакцией с клиента суть вещь противуестественная.
C>Всякие гадости типа исчерпания пулов из-за глючных клиентов — тоже можно при желании обрабатывать.
То-то и оно, что это приводит к нестабильности и риску DOS на ровном месте.
C>В любом случае. SQL-соединение по своей сути имеет состояние, да хотя бы транзакционный контекст (если только не ставить автокоммит, конечно).
Это в общем случае.
В частном случае вменяемого разработчика в SQL отъезжают только атомарные батчи:

begin tran 
--do smth
--do smth else
commit tran

Никаких открытых транзакций оставаться не должно.
C>Отсылать куски скрипта на каком-нибудь языке? На сервере — посадить этот скрипт в домен с максимально обрезаными правами.
Да. Для удобства этот язык можно назвать Structured Query Language.
C>SOAP подразумевает передачу документов и их обработку сервисами. В случае с RPC мы обычно передаем проксики для объектов на сервере и работаем с ними на клиенте. То есть, можно организовать stateful-операции сравнительно малой кровью.
Не, "stateful" и "малой кровью" — вещи несовместимые. Задача как раз избавиться от state, т.к. он очень плохо масштабируется (про коммерческие распределенные кэши я в курсе).

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, kuj, Вы писали:

kuj>>Разъясните подробнее пожалуйста.
S>Разъясняю подробнее: в каждой версии продукта мы вынуждены добавлять новые методы в API только для того, чтобы обработать новый класс запросов. Типа было GetUserByName(), теперь надо еще и GetUserByID(), FindUsersWhereNameLike(string namePart). А потом нужно еще и FindUsersWhereNameLike(string namePart, int pageSize, int pageNum, FieldName orderBy).
S>И это всё — практически без изменений модели данных; просто народу нужны разные view на наши данные.
S>Альтернатива — заставлять всех делать GetAllUsers() и потом самостоятельно сортировать/фильтровать — нереалистична в enterprize инсталляциях, где этих пользователей под сотню тыщ.
S>Получается какой-то экспоненциальный взрыв интерфейса сервиса на пустом месте.
S>Query Object в этом смысле — спасение. Но с ним нужен глаз да глаз, т.к. теряется преимущество compile-time валидации.

Кто нибудь кстати рискнул написать свой query object

? Если такие есть было б очень интересно посмотреть код...

Здравствуйте, Aviator, Вы писали:

A>>>Very Important Note: If the <key> column of a <one-to-many> association is declared NOT NULL, NHibernate may cause constraint violations when it creates or updates the association. To prevent this problem, you must use a bidirectional association with the many valued end (the set or bag) marked as inverse="true". See the discussion of bidirectional associations later in this chapter.
A>>>

A>>>Вынуждены использовать коллекции хибернета вместо стандартных.

kuj>>Э-э, а чем это мешает BLL? Ведь работаем-то все-равно через интерфейсы (IList, ICollections, etc). Или Вы не об этом, говоря, что нарушается PI?
A>Вынуждены использовать конкретную реализацию коллекции,
В каком месте вынуждает? Вот смотрю я на наш BL и в упор не вижу ни одного reference на NHibernate.

A> навязанную персистентным слоем, вместо того, что бы выбирать реализацию в соответсвии с требованиями BL.
Так и делаем. Не понимаю о чем Вы. Может проблема у Вас в том, что Вы не используете паттерн Repository?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Sinclair, Вы писали:

C>>Оптимистическое версирование — и никаких проблем (нуу... почти). Пусть держат сколько угодно — объекты блокироваться не будут.
S>Ага, зато будет расти сегмент отката. Не, управление транзакцией с клиента суть вещь противуестественная.
Не будет

Если использовать версирование на уровне приложения (тупо ввести в объекты поле "версия").

А управление транзакциями со стороны пользователя вообще мне очень противоестественным не кажется.

C>>Всякие гадости типа исчерпания пулов из-за глючных клиентов — тоже можно при желании обрабатывать.
S>То-то и оно, что это приводит к нестабильности и риску DOS на ровном месте.
Естественно, надо хорошо все продумать.

S>В частном случае вменяемого разработчика в SQL отъезжают только атомарные батчи:
S>

S>begin tran 
S>--do smth
S>--do smth else
S>commit tran
S>

S>Никаких открытых транзакций оставаться не должно.
ОЧЕНЬ редкая ситуация в правильных программах — такой подход небезопасен. Придется сначала прочитать объекты, с которыми ты будешь работать, потом сформировать пачку, а только потом отправить на сервер. Это все в разных транзакциях — а значит будет местом для race'ов. Можно бы использовать оптимистическое версирование на уровне приложения, но в SQL достаточно сложно дать гарантию, что оно будет правильно использовано тупыми пользователями API.

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

Так что utm.begin()/работаем/utm.commit() — может оказаться существенно лучше.

C>>Отсылать куски скрипта на каком-нибудь языке? На сервере — посадить этот скрипт в домен с максимально обрезаными правами.
S>Да. Для удобства этот язык можно назвать Structured Query Language.
Так его все равно на сервер пихать придется. То есть, давать клиентам модифицировать базу или выполнять принятые от них запросы. Оба варианта мне лично очень не нравятся.

C>>SOAP подразумевает передачу документов и их обработку сервисами. В случае с RPC мы обычно передаем проксики для объектов на сервере и работаем с ними на клиенте. То есть, можно организовать stateful-операции сравнительно малой кровью.
S>Не, "stateful" и "малой кровью" — вещи несовместимые. Задача как раз избавиться от state, т.к. он очень плохо масштабируется (про коммерческие распределенные кэши я в курсе).
Масштабируемые stateful-сервисы можно в большинстве случаев сделать "малой кровью", если забить на failover и тупо сделать так, чтобы клиент на протяжении сессии работал только с одним сервером кластера.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Sinclair, Вы писали:

C>>>Оптимистическое версирование — и никаких проблем (нуу... почти). Пусть держат сколько угодно — объекты блокироваться не будут.
S>>Ага, зато будет расти сегмент отката. Не, управление транзакцией с клиента суть вещь противуестественная.
C>Не будет

Если использовать версирование на уровне приложения (тупо ввести в объекты поле "версия").
Не смеши меня. Если сделать так, то мусор в базе будет копиться вечно! Кто за тебя будет устаревшие версии собирать?
C>А управление транзакциями со стороны пользователя вообще мне очень противоестественным не кажется.
А мне-кажется. Я вообще к клиентам крайне пессимистично отношусь.
и желании обрабатывать.
S>>То-то и оно, что это приводит к нестабильности и риску DOS на ровном месте.
C>Естественно, надо хорошо все продумать.
Зачем? Я, кстати, вообще не могу сходу изобрести способ более-менее уверенно отстреливать негодяев, которые тупо вешаются к тебе и "забывают" закрыть транзакцию.

S>>Никаких открытых транзакций оставаться не должно.
C>ОЧЕНЬ редкая ситуация в правильных программах — такой подход небезопасен. Придется сначала прочитать объекты, с которыми ты будешь работать, потом сформировать пачку, а только потом отправить на сервер.
Почему??? Все чтение происходит в том же батче.
C> Это все в разных транзакциях — а значит будет местом для race'ов.
Ни в коем случае. Иначе нарушаются границы транзакции и кислотность необратимо портится.
C>Можно бы использовать оптимистическое версирование на уровне приложения, но в SQL достаточно сложно дать гарантию, что оно будет правильно использовано тупыми пользователями API.

C>Ну и у нас нет возможности при таком подходе корректно взять объект, принять решение на основе данных в нем, а потом сделать обновление.

C>Так что utm.begin()/работаем/utm.commit() — может оказаться существенно лучше.
Что будет, если во время Работаем на Транстелекоме начнутся сервисные работы? MS SQL, например, мгновенно роллбэкает транзакцию при закрытии соединения. Кто это будет делать в твоем протоколе?

S>>Да. Для удобства этот язык можно назвать Structured Query Language.
C>Так его все равно на сервер пихать придется.
Я об этом и говорю.
C>То есть, давать клиентам модифицировать базу или выполнять принятые от них запросы. Оба варианта мне лично очень не нравятся.
То-то и оно. Хочется и сесть и съесть — т.е. дать клиенту веревку нужной длины, но не настолько, чтоб повесить сервер.

S>>Не, "stateful" и "малой кровью" — вещи несовместимые. Задача как раз избавиться от state, т.к. он очень плохо масштабируется (про коммерческие распределенные кэши я в курсе).
C>Масштабируемые stateful-сервисы можно в большинстве случаев сделать "малой кровью", если забить на failover и тупо сделать так, чтобы клиент на протяжении сессии работал только с одним сервером кластера.
Client affinity конечно хорошо... Но мне лично кажется не вполне оправданным ограничением.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, adontz, Вы писали:

kuj>>При чем тут запросы, если речь о процедурах. Вы, конечно же, ничего не знаете о синтаксисе того же PL/SQL и как значительно он отличается от T-SQL? PL/SQL значительно мощнее T-SQL, поэтому "downgrade" на T-SQL зачастую задача далеко не тривиальная.

A>Осталось только выяснить зачем переходить с PL/SQL на T-SQL при добавлении столбца в таблицу. kuj вы вообще клинический идиот?

Re[26]: Оформление работы с БД в корпоративных приложениях -

Клинический здесь у нас только Вы. Вам уже 5 или 6 человек хором твердят, что ORM имеет массу неоспоримых преимуществ перед ХП при создании enterprise-приложений, а Вы продолжаете упорствовать, даже не зная толком о ЧЕМ идет речь. Ламеризм хронический.

A>>>по сранению с тестированеим инсталляции в режиме обновления сущие пустяки. Никакие ORM не потмогу написать корректный апдейтер.
kuj>>Плохому танцору яйца мешают.
A>Ещё один мегагениальный комментарий от человека который никогда не занимался поддержкой инсталляций.
Ну уж куда мне до Вашей гениальности... Гениальности человека, который считает, что SQL и T-SQL это одно и то же и думает при этом, что T-SQL это декларативный язык и многое другое, что вижно невооруженным глазом, читая этот топик.

kuj>>тезис 1: хп хорошо потому, что "использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными" — false

A>true. И Синклер тебе даже дал ссылку на инструментарий.

Да если бы не Синклер, Вы бы и знать не знали об это инструментарии. Готов поспорить, что Вы его и в глаза не видели. Кроме того, речь о модульном тестировании и как мы выяснили уже с вами ХП не поддаются модульному тестированию.
Так что false, друг мой, false.

kuj>>тезис 2: хп хорошо потому, что "ХП позволяют держать в БД не только данные, но и код управления данными, обеспечивая их целостность (группировку запросов в транзакции и т.п.) на уровне хранения." — запросы в транзакции и с использованием ORM объединяются прекрасно и ORM дают даже более мощную функциональность по управлению транзакциями — false

A>Ты судя по всему плохо себе представляешь что такое целостность данных в БД с денормализованными таблицами. Ну да ладно, быть дураком личное право каждого.

Скорее Вы не представляете себе как обеспечивается целостность средствами того же Hibernate.

kuj>>тезис 3: хп хорошо потому, что "ХП напротив проще поддерживать" — нетестируемые, нечитабельные, почти не поддающиеся рефакторингу, куда более сильно привязанные к СУБД и конкретной схеме — false

A>Тебе тут несколько человек написало, что у них есть проекты на ХП и они не страдают по этому поводу.

Одно из двух: не страдают, так как не знают что они теряют, либо проекты на очень малы.

kuj>>Совершенно верно. Быть слепым это Ваше личное дело. Только не надо пытаться навязывать другим плоды своего ограниченного мышление, не обремененного знаниями современных технологий в области архитектуры enterprise-приложений и БД.

A>У меня по крайне мере есть мышление, а твои сообщения либо бессмысленны, либо противоречивы.

перлы из коллекции:

1. Re[10]: Оформление работы с БД в корпоративных приложениях -
2. Re[14]: Оформление работы с БД в корпоративных приложениях -
3. Re[8]: Оформление работы с БД в корпоративных приложениях - "Я тебе говорю. Никто в крупном проекте HQL не пользуется, это подходит только для какого-нибудь среднего онлайн-магазина." "A>>Смотря что делают хранимые процедуры. Конечно, если у тебя реализация вида 1запрос-1ХП, то пользы и от ХП мало и от их тестирования.
kuj>В том-то и дело, что хранимая процедура это черный ящик. В отличии от тестирования того же CLR — где можно делать mocking объектов. Вы пишете тест для процедуры, которая в свою очередь вызывает еще 20 процедур. В итоге Ваш тест тестирует не (только) эту процедуру, но и остальные 20. Поэтому для модульного тестирования 1 запрос — 1 ХП это вообще идеальный вариант.

То что ты написал это полный бред. Получается нельзя тестировать методы классов вызывающие другие методы. Тесты для ХП пишет тот жекто и ХП, для него она не чёрный ящик. А вот тот факт, что ХП чёрный ящик для всех остальных меня радует. Примерно так же как модификатор private. Инкапсуляция... слышал?"
4. Re[10]: Оформление работы с БД в корпоративных приложениях -
"kuj>Ликбез: транзакции выполняются на сервере. Только на сервере. Поэтому нет никакого "лучше" / "хуже".

Мысль что Hibernate и БД могут работать на разных серверах в голову не приходила?"

"kuj>Их сложно писать не "так" в силу синтаксиса и убогости T-SQL.

Ещё один миф. SQL декларативный язык, это уже обеспечивает хорошую читаемость.
"
Во-первых, как видим Вы таки не знаете разницы между T-SQL и SQL, а во-вторых, утверждение, что декларативные языки обеспечивают хорошую читабельности это просто перл среди перлов! Спорим, я могу показать Вам пару декларативных программ, написанных на Prolog и Lisp, которые Вы не сможете прочитать. А ведь это реальные декларативные языки (логики предикатов и функциональный соответственно), а не информационно-логический SQL с декларативными элементами или императивный T-SQL с декларативными элементами...

"kuj>Вот именно. Ваш проект на ХП имеет минимум "защиты от дурака". У нас активно применяется TDD, что фактически не возможно было бы, если бы проект был с использованием ХП.

TDD проверяет корректность работы, а не эффективность."

Абсолютное незнание термина TDD.

5. Re[12]: Оформление работы с БД в корпоративных приложениях -

"Видишь ли, Hibernate как правило наботает в tier бизнесс-логики." это 5 баллов. Незнание архитектуры современных enterprise-систем на лицо.

6. "Re[10]: Оформление работы с БД в корпоративных приложениях -"
опять же незнание принципов модульного тестирования на лицо.

7. Re[8]: Оформление работы с БД в корпоративных приложениях -
"TDD замечательно бывает только на SQL" Это круто. Это 5 баллов.

8. Re[19]: Оформление работы с БД в корпоративных приложениях -
"ручное юнит-тестирование. Еще один замечательный перл в коллекцию.

и в продолжении

Re[19]: Оформление работы с БД в корпоративных приложениях -

"А где я тут сказал юнит-тесты?" — и этот человек обвиняет меня в противоречивости?

Декларативность языка обеспечивает хорошую читабельность? Это 5 баллов.

9. Re[6]: Оформление работы с БД в корпоративных приложениях -
"Именно тот факт, что ORM являясь очень удобными средствами никак не контроллирующим разработчика и приводит к отказу от ORM в действительно крупных проектах. " Еще один перл в копилку.

и т.д. можно продолжать и продолжать...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Cyberax, Вы писали:

S>>у SQL, конечно же, есть свои недостатки. Но, имхо, невредно было бы придумать схему с преимуществами обоих подходов.
C>Может вам стоит на Spring+Hibernate в Java посмотреть?

Там множество этих проблем уже решено.
Есть уже, кстати, порт под .NET и NHibernate — Spring.NET

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Aviator, Вы писали:

A>Кто нибудь кстати рискнул написать свой query object

? Если такие есть было б очень интересно посмотреть код...

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

... << RSDN@Home 1.2.0 alpha rev. 771>>

Здравствуйте, Aviator, Вы писали:

A>Кто нибудь кстати рискнул написать свой query object

? Если такие есть было б очень интересно посмотреть код...

А почему бы не взять ейный из того же Hibernate и не переделать под свои нужды, если очень хочется?

Ради интереса посмотрю сегодня что он из себя представляет изнутри.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Sinclair, Вы писали:

S>>>Ага, зато будет расти сегмент отката. Не, управление транзакцией с клиента суть вещь противуестественная.
C>>Не будет

Если использовать версирование на уровне приложения (тупо ввести в объекты поле "версия").
S>Не смеши меня. Если сделать так, то мусор в базе будет копиться вечно! Кто за тебя будет устаревшие версии собирать?
То есть? Я не предлагаю ХРАНИТЬ предидущие версии. Просто добавляешь в объекты поле "версия", которое инкрементируется при каждом обновлении, и при коммите проверяешь, что поле "версия" в базе равно твоему, иначе кидаешь исключение. Тогда не нужно никаких больших сегментов отката.

S>>>То-то и оно, что это приводит к нестабильности и риску DOS на ровном месте.
C>>Естественно, надо хорошо все продумать.
S>Зачем? Я, кстати, вообще не могу сходу изобрести способ более-менее уверенно отстреливать негодяев, которые тупо вешаются к тебе и "забывают" закрыть транзакцию.
Тупой таймаут и ограничение на N параллельных коннектов. Для длительных операций, которые все-таки не влазят в таймаут, просто делаем специальные отдельные сервисы.

C>>ОЧЕНЬ редкая ситуация в правильных программах — такой подход небезопасен. Придется сначала прочитать объекты, с которыми ты будешь работать, потом сформировать пачку, а только потом отправить на сервер.
S>Почему??? Все чтение происходит в том же батче.
Тогда вся обработка должна быть написана на SQL. Собственно, тогда ВООБЩЕ нет особого смысла выделять бизнес-логику из БД.

C>>Так что utm.begin()/работаем/utm.commit() — может оказаться существенно лучше.
S>Что будет, если во время Работаем на Транстелекоме начнутся сервисные работы? MS SQL, например, мгновенно роллбэкает транзакцию при закрытии соединения. Кто это будет делать в твоем протоколе?
Менеджер транзакций, работающий на сервере. Ему указывается таймаут (который передается в том числе и транзакционным источникам, таким как соединения с БД), по истечение которого — транзакция прибьется. По крайней мере, у меня так и сделано.

Если канал ОЧЕНЬ ненадежный, то возможна ситуация, когда один клиент будет постоянно отваливаться и оставлять соединения умирать по таймауту. Для этого нужно поставить "автокиллер", который будет насильно прибивать предыдущие повисшие транзакции клиента, когда от клиента будут приходить новые запросы.

C>>Масштабируемые stateful-сервисы можно в большинстве случаев сделать "малой кровью", если забить на failover и тупо сделать так, чтобы клиент на протяжении сессии работал только с одним сервером кластера.
S>Client affinity конечно хорошо... Но мне лично кажется не вполне оправданным ограничением.
На практике работает вроде нормально.

Здравствуйте, kejroot, Вы писали:

kuj>>Очень рекомендую Castle Windsor (или MicroKernel) для уменьшения зависимостей.

kuj>>http://www.castleproject.org/container/index.html
K>еще слыхал про NanoContainer (или PicoContainer),
K>в MS CAB используется свой ObjectBuilder.
K>но видимо Windsor проще
Да их приличное множество существует и принципиальных различий междуними не много... Поэтому скорее дело вкуса.

Вот еще хорошая серия статей по Castle Windsor и IoC
http://dotnetslackers.com/articles/designpatterns/InversionOfControlAndDependencyInjectionWithCastleWindsorContainerPart1.aspx

K>помойму вообще лучше всего делать на каком-нить каркасе, типа Spring или Eclipse RCP., там и сразу контейнер интегрирован, и большая часть работы сделана
Совершенно верно.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

Настоятельно советую обоим джентльменам воздержаться от обсуждения квалификации друг друга.
Вы уже успели оба на полугодовой бан наобщаться!
Подходы к разработке можете обсуждать сколько угодно.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Cyberax, Вы писали:
C>То есть? Я не предлагаю ХРАНИТЬ предидущие версии. Просто добавляешь в объекты поле "версия", которое инкрементируется при каждом обновлении, и при коммите проверяешь, что поле "версия" в базе равно твоему, иначе кидаешь исключение. Тогда не нужно никаких больших сегментов отката.
А, ну то есть optimistic locking. Извини, протупил.
Это тоже не панацея. Будут неизбежные проблемы. Для начала, не удастся воспользоваться встроенной механикой СУБД, придется все изменения накапливать в памяти и откладывать их до коммита. Далее, в стоимость коммита начинает входить повторное чтение всех прочитанных в транзакции данных.
Версионники фактически делают то же самое, только transaction changes хранятся в базе, а не в памяти.
Длина транзакции неизбежно влияет на стоимость

S>>Зачем? Я, кстати, вообще не могу сходу изобрести способ более-менее уверенно отстреливать негодяев, которые тупо вешаются к тебе и "забывают" закрыть транзакцию.
C>Тупой таймаут и ограничение на N параллельных коннектов.
Значит, будет DDoS. Это всё обходится.
C> Для длительных операций, которые все-таки не влазят в таймаут, просто делаем специальные отдельные сервисы.
Вот это меня и беспокоит: то, что мы наворачиваем целую сеть решений только для проблем, которые сами же и создали. Мне бы хотелось, чтобы инфраструктура решала значительно больше проблем, чем создавала бы

C>Тогда вся обработка должна быть написана на SQL. Собственно, тогда ВООБЩЕ нет особого смысла выделять бизнес-логику из БД.
Совершенно верно. В идеале, вместо SQL был бы нормальный язык высокого уровня, который бы не приносил такого страшного performance penalty на не-SQL операциях.
Вообще, курсоры в T-SQL, к примеру, так плохи не потому, что вообще плохи, а потому, что код курсора чудовищно медленно интерпретируется.
Если бы код компилировался в нативную программу, то особой разницы в стейтменте с UDF и курсоре не было бы.

S>>Что будет, если во время Работаем на Транстелекоме начнутся сервисные работы? MS SQL, например, мгновенно роллбэкает транзакцию при закрытии соединения. Кто это будет делать в твоем протоколе?
C>Менеджер транзакций, работающий на сервере. Ему указывается таймаут (который передается в том числе и транзакционным источникам, таким как соединения с БД), по истечение которого — транзакция прибьется. По крайней мере, у меня так и сделано.
Ну, это может быть решением, а может и не быть.

C>Если канал ОЧЕНЬ ненадежный, то возможна ситуация, когда один клиент будет постоянно отваливаться и оставлять соединения умирать по таймауту. Для этого нужно поставить "автокиллер", который будет насильно прибивать предыдущие повисшие транзакции клиента, когда от клиента будут приходить новые запросы.
Хочется чего-то более простого; причем очевидный способ — это именно скармливать запросы целиком. Вот HTTP построен именно по этой схеме, и он прямо-таки фантастически удачен.
S>>Client affinity конечно хорошо... Но мне лично кажется не вполне оправданным ограничением.
C>На практике работает вроде нормально.
У нас тоже есть опыт его эксплуатации. Может быть, я просто отношусь к нему с предубеждением.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>А, ну то есть optimistic locking. Извини, протупил.
S>Это тоже не панацея. Будут неизбежные проблемы. Для начала, не удастся воспользоваться встроенной механикой СУБД, придется все изменения накапливать в памяти и откладывать их до коммита.
Да, но обычно это не так уж сильно плохо. Кроме того, в большинстве случаев и так это придется делать.

S>Далее, в стоимость коммита начинает входить повторное чтение всех прочитанных в транзакции данных.
Нет, стандартный прием для версирования: "UPDATE ... SET ... WHERE id=? AND version=?". Если этот оператор вернет 0 (ни одного ряда не обновлено) — то значит у нас оптимистическая ошибка. Можно это сделать и batch'ем для нескольких обновлений.

S>Версионники фактически делают то же самое, только transaction changes хранятся в базе, а не в памяти.
S>Длина транзакции неизбежно влияет на стоимость

Обычно для сервисов нужно минимизировать длину. Кроме того, тут у нас затраты на память будут на стороне клиента, а не сервера. Так что если он решит похулиганить — то ССЗБ.

S>>>Зачем? Я, кстати, вообще не могу сходу изобрести способ более-менее уверенно отстреливать негодяев, которые тупо вешаются к тебе и "забывают" закрыть транзакцию.
C>>Тупой таймаут и ограничение на N параллельных коннектов.
S>Значит, будет DDoS. Это всё обходится.
Так пусть себе DDoSит себя — отъест свои соединия и отвалится. На остальных клиентов влиять не будет.

C>> Для длительных операций, которые все-таки не влазят в таймаут, просто делаем специальные отдельные сервисы.
S>Вот это меня и беспокоит: то, что мы наворачиваем целую сеть решений только для проблем, которые сами же и создали. Мне бы хотелось, чтобы инфраструктура решала значительно больше проблем, чем создавала бы

Так ее надо один раз сделать — и она будет решать. Мы вот себе сделали такую неплохую инфраструктуру, в которой есть фичи, которых нет ни в одном существующем протоколе remoting'а

C>>Тогда вся обработка должна быть написана на SQL. Собственно, тогда ВООБЩЕ нет особого смысла выделять бизнес-логику из БД.
S>Совершенно верно. В идеале, вместо SQL был бы нормальный язык высокого уровня, который бы не приносил такого страшного performance penalty на не-SQL операциях.
Еще он сам по себе слишком жуткий по сравнению даже с VB.

S>Вообще, курсоры в T-SQL, к примеру, так плохи не потому, что вообще плохи, а потому, что код курсора чудовищно медленно интерпретируется.
S>Если бы код компилировался в нативную программу, то особой разницы в стейтменте с UDF и курсоре не было бы.
Ну это возможно, во всяких там DB2 и прочих — там процедуры компилируются в С, а потом и в машинный код.

C>>Если канал ОЧЕНЬ ненадежный, то возможна ситуация, когда один клиент будет постоянно отваливаться и оставлять соединения умирать по таймауту. Для этого нужно поставить "автокиллер", который будет насильно прибивать предыдущие повисшие транзакции клиента, когда от клиента будут приходить новые запросы.
S>Хочется чего-то более простого; причем очевидный способ — это именно скармливать запросы целиком. Вот HTTP построен именно по этой схеме, и он прямо-таки фантастически удачен.
Тогда будет ваша проблема с кучей мелких тривиальных операций. Кстати, и HTTP не так уж удачен для многих задач.

S>>>Client affinity конечно хорошо... Но мне лично кажется не вполне оправданным ограничением.
C>>На практике работает вроде нормально.
S>У нас тоже есть опыт его эксплуатации. Может быть, я просто отношусь к нему с предубеждением.
Мне тоже не нравятся не надежные на 100% решения, но как практический компромис без кластерного кэша — сойдет.

Здравствуйте, kuj, Вы писали:

kuj>Есть уже, кстати, порт под .NET и NHibernate — Spring.NET

...вполне, ИМХО, приятный и функциональный.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Sinclair, Вы писали:

A>>Ну вообще-то из примера вроде было видно, что группируются таким образом только то, над чем проводятся однотипные операции. Login и Password я не вынес. Во-первых, это ударит по производительности, во-вторых, с ними проводится совсем другой набор операций.
S>Я это веду к тому, что раз уж такие "резиновые" поля так отличаются от "основных", то может иметь смысл отразить это и на уровне апп.сервера. Т.е. так и добавить в Person свойство CustomProperties типа Dictionary<string, object>. Тогда добавление нового свойста не затронет не только БД, но даже и код перекомпилировать не придется!

Ну, собственно, на уровне DAL это так и надо сделать. Если удасться на уровне BL, то совсем здорово. В Presentation по-любому придётся специфически обрабатывать, от этого не убежать.

Здравствуйте, Sinclair, Вы писали:

S>Например, есть методы CreateUser, CreateSite, AssignSiteToUser. Эти методы нужны, т.к. вызываются в некоторых бизнес-сценариях. Теперь обнаруживается сценарий, при котором нужно сразу создать пользователя, сайт, и присвоить сайт пользователю. Проблема в том, что если какое-то из действий не пройдет, то нужно откатывать всё. Конечно, можно сделать с клиента цепочку try с обратными действиями в catch:
S>Но это-ненадежная схема, т.к. если в процессе порвется коннект, то Delete*() вызвать не удастся у нас так и останется мусор в сервере.
S>Поэтому мы делаем метод CreateUserWithSite с совершенно тривиальной реализацией.

Ну ещё можно соединение BL<->DAL сделать Stateful (интерфейс BL при этом останется stateless) и ввести DAL-side транзакции. Тогда, скажем, не нужная BL операция DeleteUser не будет присутствовать в интерфейсе DAL, что тоже плюс.

Вызываешь
BeginTransaction()
User user = CreateUser(...)
CreateSite(user)
CommitTransaction()

Транзакции на уровне DAL, учитывая что у тебя будут упорядоченные пары действие-противодействие, конечно всё усложнят, но не геморрой.

Здравствуйте, kuj, Вы писали:

A>>Осталось только выяснить зачем переходить с PL/SQL на T-SQL при добавлении столбца в таблицу. kuj вы вообще клинический идиот?
kuj>Re[26]: Оформление работы с БД в корпоративных приложениях -

Это другая ветка, ты даже сам не знаешь на что отвечаешь. Что и требовалось доказать.

A>>true. И Синклер тебе даже дал ссылку на инструментарий.
kuj>Да если бы не Синклер, Вы бы и знать не знали об это инструментарии.

Какое это имеет отношение к наличию или функциональности инструментария? Ты вообще со мной воюешь или против ХП? Определяйся.

A>>Ты судя по всему плохо себе представляешь что такое целостность данных в БД с денормализованными таблицами. Ну да ладно, быть дураком личное право каждого.
kuj>Скорее Вы не представляете себе как обеспечивается целостность средствами того же Hibernate.

При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.

A>>Тебе тут несколько человек написало, что у них есть проекты на ХП и они не страдают по этому поводу.
kuj>Одно из двух: не страдают, так как не знают что они теряют, либо проекты на очень малы.

Ага, то есть ты готов придумать что угодно, лишь бы не признавать что с ХП можно дружно жить.

A>>У меня по крайне мере есть мышление, а твои сообщения либо бессмысленны, либо противоречивы.
kuj>перлы из коллекции:

kuj>и т.д. можно продолжать и продолжать...

Ага, просто перечислил несколько читат вырванных из контекста. Шикарно. Объяснения почему это так, а не эдак от тебя нет. Толковых ответав нет. Просто регулярно постишь провокационные сообщения на тему "вы не разбираетесь". Пустышка.

Здравствуйте, Sinclair, Вы писали:

S>Настоятельно советую обоим джентльменам воздержаться от обсуждения квалификации друг друга.
S>Вы уже успели оба на полугодовой бан наобщаться!
S>Подходы к разработке можете обсуждать сколько угодно.

И правда, пора тормозить. Спасибо за предупреждение. Если удалишь перепалку, думаю все скажут спасибо. Полезного там крайне мало.

Здравствуйте, adontz, Вы писали:

A>>>Ты судя по всему плохо себе представляешь что такое целостность данных в БД с денормализованными таблицами. Ну да ладно, быть дураком личное право каждого.
kuj>>Скорее Вы не представляете себе как обеспечивается целостность средствами того же Hibernate.
A>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
То есть? Если не используем автокоммит — то транзакция в БД, в которой работал Hibernate, просто откатится через некоторое время по таймауту.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kuj, Вы писали:

A>>>Осталось только выяснить зачем переходить с PL/SQL на T-SQL при добавлении столбца в таблицу. kuj вы вообще клинический идиот?
kuj>>Re[26]: Оформление работы с БД в корпоративных приложениях -

A>Это другая ветка, ты даже сам не знаешь на что отвечаешь. Что и требовалось доказать.

Не вижу смысла плодить ответы на Ваш бред в разных ветках.

A>>>true. И Синклер тебе даже дал ссылку на инструментарий.
kuj>>Да если бы не Синклер, Вы бы и знать не знали об это инструментарии.

A>Какое это имеет отношение к наличию или функциональности инструментария? Ты вообще со мной воюешь или против ХП? Определяйся.

Самое непосредственное, а что именно было сказано в квоте, которую Вы поскипали.

A>>>Ты судя по всему плохо себе представляешь что такое целостность данных в БД с денормализованными таблицами. Ну да ладно, быть дураком личное право каждого.
kuj>>Скорее Вы не представляете себе как обеспечивается целостность средствами того же Hibernate.

A>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
Кто Вам эту чушь сказал? Еще один пример полной некомпетентности. ликбез: при обрыве связи происходит rollback транзакции.

A>>>Тебе тут несколько человек написало, что у них есть проекты на ХП и они не страдают по этому поводу.
kuj>>Одно из двух: не страдают, так как не знают что они теряют, либо проекты на очень малы.

A>Ага, то есть ты готов придумать что угодно, лишь бы не признавать что с ХП можно дружно жить.

Дружить можете с кем угодно, а нам работать надо.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Cyberax, Вы писали:

A>>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
C>То есть? Если не используем автокоммит — то транзакция в БД, в которой работал Hibernate, просто откатится через некоторое время по таймауту.

Это значит надо все бизнес-транзакции обрачивать в транзакции БД?

Здравствуйте, kuj, Вы писали:

A>>Это другая ветка, ты даже сам не знаешь на что отвечаешь. Что и требовалось доказать.
kuj>Не вижу смысла плодить ответы на Ваш бред в разных ветках.

Так, во-первых кончаем друшг другу хамить. Предупреждение от модератора тебе по барабану?
Во-вторых, сперва уж научись пользоваться древовидными форумами, а потом лезь в сложноструктурированные дискуссии. Угадывать на что ты ответил в не той ветке ни у меня, ни у кого-либо ещё нет никакого желания.

A>>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
kuj>Кто Вам эту чушь сказал? Еще один пример полной некомпетентности. ликбез: при обрыве связи происходит rollback транзакции.

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

Здравствуйте, adontz, Вы писали:

A>>>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
kuj>>Кто Вам эту чушь сказал? Еще один пример полной некомпетентности. ликбез: при обрыве связи происходит rollback транзакции.

A>Так как у нас есть бизнес-транзакции, завершение или откат транзакции БД не обозначают, что данные в согласованном состоянии. И это... перестаём хамить.

Да при чем тут вообще бизнес-транзакции? Или у вас бизнесс-транзакции в ХПы запиханы?

Вообщем неудачная попытка съехать с темы.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>Да при чем тут вообще бизнес-транзакции? Или у вас бизнесс-транзакции в ХПы запиханы?

Ну у Синклера же был пример в соседней ветке про CreateUser, CreateSite и CreateUserWithSite. Найди и почитай. Фактически да, бизнес-транзакция оказалась в БД, хотя там ей, конечно, делать нечего. Это именно из-за невозможности (огромной трудоёмкости) сделать устойчивую к отказам оборудования транзакцию выше уровня DAL.

Здравствуйте, adontz, Вы писали:

kuj>>Да при чем тут вообще бизнес-транзакции? Или у вас бизнесс-транзакции в ХПы запиханы?

A>Ну у Синклера же был пример в соседней ветке про CreateUser, CreateSite и CreateUserWithSite. Найди и почитай. Фактически да, бизнес-транзакция оказалась в БД, хотя там ей, конечно, делать нечего. Это именно из-за невозможности (огромной трудоёмкости) сделать устойчивую к отказам оборудования транзакцию выше уровня DAL.

Чушь.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

A>>Ну у Синклера же был пример в соседней ветке про CreateUser, CreateSite и CreateUserWithSite. Найди и почитай. Фактически да, бизнес-транзакция оказалась в БД, хотя там ей, конечно, делать нечего. Это именно из-за невозможности (огромной трудоёмкости) сделать устойчивую к отказам оборудования транзакцию выше уровня DAL.
kuj>Чушь.

Если не трудно, вырази свою мысль чуть подробнее. Например как бы ты решал эту задачу (бизнес-транзакция CreateUser+CreateSite) с учётом возможных аппаратных сбоев.

Здравствуйте, adontz, Вы писали:

A>>>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
C>>То есть? Если не используем автокоммит — то транзакция в БД, в которой работал Hibernate, просто откатится через некоторое время по таймауту.
A>Это значит надо все бизнес-транзакции обрачивать в транзакции БД?

Те которые могут нарушить целостность БД — обязательно. Если нужны долгие бизнес-транзакции — используем оптимистическое версирование и т.п. В общем, у меня это вполне получается.

Здравствуйте, Cyberax, Вы писали:

A>>>>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
C>>>То есть? Если не используем автокоммит — то транзакция в БД, в которой работал Hibernate, просто откатится через некоторое время по таймауту.
A>>Это значит надо все бизнес-транзакции обрачивать в транзакции БД?

C>Те которые могут нарушить целостность БД — обязательно.

Ну да, а потом мне рассказывают что ХП — зло. А на поверку у всех всё в БД и даже не в виде poor mans DAL, а в виде poor mans BL. Спасибо, посмеялся

Здравствуйте, adontz, Вы писали:

A>>>>>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
C>>>>То есть? Если не используем автокоммит — то транзакция в БД, в которой работал Hibernate, просто откатится через некоторое время по таймауту.
A>>>Это значит надо все бизнес-транзакции обрачивать в транзакции БД?

C>>Те которые могут нарушить целостность БД — обязательно.

A>Ну да, а потом мне рассказывают что ХП — зло.
Естественно зло. И вам уже 100 раз объяснили почему. Уж очень туго до Вас доходит.

A>А на поверку у всех всё в БД и даже не в виде poor mans DAL, а в виде poor mans BL. Спасибо, посмеялся

Вы хоть поняли что сказали?

Еще раз для тех, кто в танке: ORM в частности NHibernate дает более богатый инструментарий для управления транзакциями БД.

Бизнес-транзакции же понятие высокоуровневое и во многих случаях абстрактное. Есть, например, BTP — Business Transaction Protocol для организации БТ через Интернет. Какое он по-вашему имеет отношение к техническим транзакциям какой-то конкретной БД? Никакого.

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

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

C>>>>То есть? Если не используем автокоммит — то транзакция в БД, в которой работал Hibernate, просто откатится через некоторое время по таймауту.
A>>>Это значит надо все бизнес-транзакции обрачивать в транзакции БД?

Нет. Только те части бизнес-транзакций, которые в случае сбоя могут нарушить целостность данных.

C>>Те которые могут нарушить целостность БД — обязательно.
A>Ну да, а потом мне рассказывают что ХП — зло. А на поверку у всех всё в БД и даже не в виде poor mans DAL, а в виде poor mans BL. Спасибо, посмеялся

Нет.

К примеру, стандартная задача — несколько web-страниц с формочками. Это представляет из себя одну бизнес-транзакцию, она состоит из нескольких read-only транзакций с базой (показываем формочки) и финальной записи (нажили "OK" на последней форме).

Соответственно, эта вот финальная запись должна _обязательно_ выполнятся в одной транзакции БД. Иначе у нас есть возможность нарушить целостность.

Здравствуйте, kuj, Вы писали:

A>>Ну да, а потом мне рассказывают что ХП — зло.
kuj>Естественно зло. И вам уже 100 раз объяснили почему. Уж очень туго до Вас доходит.

Лично ты вообще ничего не объяснил. Только поохал.

A>>А на поверку у всех всё в БД и даже не в виде poor mans DAL, а в виде poor mans BL. Спасибо, посмеялся

kuj>Вы хоть поняли что сказали?

Не хами.

kuj>Еще раз для тех, кто в танке: ORM в частности NHibernate дает более богатый инструментарий для управления транзакциями БД.

Но не обеспечивает устойчивость к аппаратным сбоям.

kuj>Бизнес-транзакции же понятие высокоуровневое и во многих случаях абстрактное. Есть, например, BTP — Business Transaction Protocol для организации БТ через Интернет. Какое он по-вашему имеет отношение к техническим транзакциям какой-то конкретной БД? Никакого.

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

kuj>И этот человек еще обвинял меня в непонимании разницы между бизнес-транзакциями и транзакциями БД, когда сам ни того, ни другого не понимает. Смешно.

Смешно, что ты не даёшь ответов на вопросы только декларируя неправоту оппонента, но не объясняя сути неправоты и не приводя правильного решения, а потом надеешься на понимание.
Я всё ещё жду ответа тут http://www.rsdn.ru/Forum/Message.aspx?mid=2674656&only=1

Здравствуйте, Cyberax, Вы писали:

C>К примеру, стандартная задача — несколько web-страниц с формочками. Это представляет из себя одну бизнес-транзакцию, она состоит из нескольких read-only транзакций с базой (показываем формочки) и финальной записи (нажили "OK" на последней форме).

Read-only не интересно.

C>Соответственно, эта вот финальная запись должна _обязательно_ выполнятся в одной транзакции БД. Иначе у нас есть возможность нарушить целостность.

Есть случаи гораздо сложнее. Вот реальный пример.
Некоторая околоавтомобильная система. Пользователи двух типов: клиенты — владельцы автомобилей и обслуживающий первонал. Табличка Users на всех одна (достаточно много общих действий) со столбцом Kind. У клиентов объязательно есть автомобиль. Может быть не один, но один точно. У обслуживающего персонала — нет.
Соответственно есть некоторое окно по редактированию списка автомобилей доступное только для пользователя-клиента. При его написании подразумевалось, что множество автомобилей не пусто (по условиям ТЗ). Скажем, это выражается в том, что всегда вызывается _carListView.SetSelection(0) для выделения первого автомобиля в списке.
Сценрий. Добавляем нового клиента вводя его данные и данные его первого автомобиля. Вызывается CreateUser, соединение с БД рвётся, try/catch ловит какой-то бред.
Восстанавливаем систему. Пользователь есть в списке, но окно редактирования списка автомобилей при попытке открытия вылетает с исключением. Удалить пользователя нельзя (условие ТЗ).
Конечно решения есть. По уму на стороне DAL должен был вестись лог транзакций и после восстановления соединения пользователь должен был быть удалён. Ну или не лог транзакций но какой-то способ отката. Кто это будет писать в таком виде? Конечно, сделают ХП для CreateUserAndFirstCar, CreateNextCar с большим количеством общего кода потому что так намного проще.
Может быть и менее экстремально, но не лучше — после CreateUser кто-то просто считал список пользователей. Транзакции это ведь не только возможность отката, но и уровни изоляции. Да, проблема решается Refresh'ем, только это не решение вовсе. Так что корректные бизнес-транзакции не на уровне БД это редкстный геморрой на самом деле.

Здравствуйте, adontz, Вы писали:

kuj>>Еще раз для тех, кто в танке: ORM в частности NHibernate дает более богатый инструментарий для управления транзакциями БД.

A>Но не обеспечивает устойчивость к аппаратным сбоям.

Обеспечивает ровно в той же мере, что и хранимые процедуры. Хватит уже чушь молоть.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

A>>Но не обеспечивает устойчивость к аппаратным сбоям.
kuj>Обеспечивает ровно в той же мере, что и хранимые процедуры. Хватит уже чушь молоть.

Объясни как и не хами. Я привёл несколько сценариев когда обеспечивает. Аргументированно опровергни.

Здравствуйте, adontz, Вы писали:

C>>Соответственно, эта вот финальная запись должна _обязательно_ выполнятся в одной транзакции БД. Иначе у нас есть возможность нарушить целостность.

A>Есть случаи гораздо сложнее. Вот реальный пример.
A>Некоторая околоавтомобильная система. Пользователи двух типов: клиенты — владельцы автомобилей и обслуживающий первонал. Табличка Users на всех одна (достаточно много общих действий) со столбцом Kind. У клиентов объязательно есть автомобиль. Может быть не один, но один точно. У обслуживающего персонала — нет.
A>Соответственно есть некоторое окно по редактированию списка автомобилей доступное только для пользователя-клиента. При его написании подразумевалось, что множество автомобилей не пусто (по условиям ТЗ). Скажем, это выражается в том, что всегда вызывается _carListView.SetSelection(0) для выделения первого автомобиля в списке.
A>Сценрий. Добавляем нового клиента вводя его данные и данные его первого автомобиля. Вызывается CreateUser, соединение с БД рвётся, try/catch ловит какой-то бред.
A>Восстанавливаем систему. Пользователь есть в списке, но окно редактирования списка автомобилей при попытке открытия вылетает с исключением. Удалить пользователя нельзя (условие ТЗ).
A>Конечно решения есть. По уму на стороне DAL должен был вестись лог транзакций и после восстановления соединения пользователь должен был быть удалён. Ну или не лог транзакций но какой-то способ отката. Кто это будет писать в таком виде? Конечно, сделают ХП для CreateUserAndFirstCar, CreateNextCar с большим количеством общего кода потому что так намного проще.
A>Может быть и менее экстремально, но не лучше — после CreateUser кто-то просто считал список пользователей. Транзакции это ведь не только возможность отката, но и уровни изоляции. Да, проблема решается Refresh'ем, только это не решение вовсе. Так что корректные бизнес-транзакции не на уровне БД это редкстный геморрой на самом деле.

Еще раз: есть системы, в которых ЕСТЬ бизнес-транзакции, но НЕТ БД.

Сценарий, приведенный вами, как-раз элементарно решается средствами NHibernate — открыв транзакцию БД в начале, и закоммитив ее после добавления автомобиля.
Более того, для такого простого сценария нет никакой необходимости держать транзакцию открытой все это время:
Создается объект User, в коллекцию Cars добавляется автомобиль, а по окончании делается пакетный Flush в БД внутри транзакции (с гораздо меньшим временем жизни). Все.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Но не обеспечивает устойчивость к аппаратным сбоям.
kuj>>Обеспечивает ровно в той же мере, что и хранимые процедуры. Хватит уже чушь молоть.

A>Объясни как и не хами. Я привёл несколько сценариев когда обеспечивает. Аргументированно опровергни.

Что опровергнуть? Что NHibernate уступает ХП в плане управления транзакциями БД? Вам разные люди твердят, что ничем не уступает, и напротив предоставляет дополнительный инструментарий, а Вы продолжаете упорствовать?
Читайте документацию по NHibernate (Hibernate), ADO.NET (JDBC) пока не поймете этого. Заниматься восполнением пробелов в вашем образовании я не собираюсь.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

A>>Объясни как и не хами. Я привёл несколько сценариев когда обеспечивает. Аргументированно опровергни.
kuj>Что опровергнуть? Что NHibernate уступает ХП в плане управления транзакциями БД? Вам разные люди твердят, что ничем не уступает, и напротив предоставляет дополнительный инструментарий, а Вы продолжаете упорствовать?
kuj>Читайте документацию по NHibernate (Hibernate), ADO.NET (JDBC) пока не поймете этого. Заниматься восполнением пробелов в вашем образовании я не собираюсь.

Опять нет ответа, одно хамство. Это уже закономерность какая-то...

Здравствуйте, kuj, Вы писали:

kuj>Сценарий, приведенный вами, как-раз элементарно решается средствами NHibernate — открыв транзакцию БД в начале, и закоммитив ее после добавления автомобиля.

Hibernate это уровень DAL и поддерживать бизнес транзакции он не в состоянии. То что ты указал это не решение средствами Hibernate, потому что ты открываешь транзакцию БД. Если у тебя бизнес-транзакция CreateUser+CreateCar+SendSmsToAdmin, то Hibernate тут ничем не поможет, потому что бизнес-транзакции вне компетенции Hibernate.

kuj>Более того, для такого простого сценария нет никакой необходимости держать транзакцию открытой все это время:
kuj>Создается объект User, в коллекцию Cars добавляется автомобиль, а по окончании делается пакетный Flush в БД внутри транзакции (с гораздо меньшим временем жизни). Все.

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

Здравствуйте, adontz, Вы писали:

C>>К примеру, стандартная задача — несколько web-страниц с формочками. Это представляет из себя одну бизнес-транзакцию, она состоит из нескольких read-only транзакций с базой (показываем формочки) и финальной записи (нажили "OK" на последней форме).
A>Read-only не интересно.
Можно read/write, но там уже несколько вариантов.

A>Соответственно есть некоторое окно по редактированию списка автомобилей доступное только для пользователя-клиента. При его написании подразумевалось, что множество автомобилей не пусто (по условиям ТЗ). Скажем, это выражается в том, что всегда вызывается _carListView.SetSelection(0) для выделения первого автомобиля в списке.
A>Сценрий. Добавляем нового клиента вводя его данные и данные его первого автомобиля. Вызывается CreateUser, соединение с БД рвётся, try/catch ловит какой-то бред.
A>Восстанавливаем систему. Пользователь есть в списке, но окно редактирования списка автомобилей при попытке открытия вылетает с исключением. Удалить пользователя нельзя (условие ТЗ).
Решается не просто, а очень просто. При регистрации пользователя данные накапливаются в сессии, а добавление первого автомобиля — часть регистрации.

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

Кстати, для именно таких сценариев в Java сделали библиотеку под названием "Seam" (которая, естественно, может использовать Hibernate), там оно всё красиво инкапсюлируется в виде "conversation"'ов.

A>Конечно решения есть. По уму на стороне DAL должен был вестись лог транзакций и после восстановления соединения пользователь должен был быть удалён. Ну или не лог транзакций но какой-то способ отката. Кто это будет писать в таком виде? Конечно, сделают ХП для CreateUserAndFirstCar, CreateNextCar с большим количеством общего кода потому что так намного проще.
Ты предлагаешь черезчур навороченое и сложное решение. Можно все делать намного проще и надежнее.

Здравствуйте, Cyberax, Вы писали:

C>В конце регистрации — коммит всей накопленой информации в базу в одной транзакции. Тогда у нас гарантировано система всегда будет в целостном состоянии — если у нас во время коммита в сервер приложений попадет метеорит, то транзакция в базе данных потом спокойно откатится по таймауту. С точки зрения остальных клиентов все изменения тоже атомарны.

вот об том и речь., что ты не в состоянии дёшево отганизовать транзакции вне БД и делаешь две операции CreateUserWithCar и CreateCar имеющие много общего кода (копи-паст, если по простому).

Здравствуйте, adontz, Вы писали:

kuj>>Сценарий, приведенный вами, как-раз элементарно решается средствами NHibernate — открыв транзакцию БД в начале, и закоммитив ее после добавления автомобиля.

A>Hibernate это уровень DAL и поддерживать бизнес транзакции он не в состоянии. То что ты указал это не решение средствами Hibernate, потому что ты открываешь транзакцию БД. Если у тебя бизнес-транзакция CreateUser+CreateCar+SendSmsToAdmin, то Hibernate тут ничем не поможет, потому что бизнес-транзакции вне компетенции Hibernate.

CreateUser+CreateCar+CommitTransaction+SendSmsToAdmin. CommitTransaction все накопленные в сессии данные сбрасывает внутри одной транзакции в базу.

Вы все еще не понимаете?

kuj>>Более того, для такого простого сценария нет никакой необходимости держать транзакцию открытой все это время:
kuj>>Создается объект User, в коллекцию Cars добавляется автомобиль, а по окончании делается пакетный Flush в БД внутри транзакции (с гораздо меньшим временем жизни). Все.

A>Время жизни не имеет абсолютно никакого принципиального значения в данном случае.
A>Суть претензии в том, что в задачи ORM не вхоит организация бизнес транзакций.
В задачи хранимых процедур организация бизнес-транзакций тоже не входит. Все еще не понимаете?

A>Либо эта задача решается в лоб, что приводит к написания большого объёма достаточно сложного кода, либо сваливается на БД в которых транзакции уже есть.
(вздыхая) почитайте чтоли на досуге про BTP и как бизнес-транзакции могут существовать без помощи транзакций БД...

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>CreateUser+CreateCar+CommitTransaction+SendSmsToAdmin. CommitTransaction все накопленные в сессии данные сбрасывает внутри одной транзакции в базу.
kuj>Вы все еще не понимаете?

Это ты не понимаешь, что если SMS не отослался, то создание юзера надо откатить.
CreateUser+CreateCar+SendSmsToAdmin+CommitTransaction

БД не пуп земли.

A>>Время жизни не имеет абсолютно никакого принципиального значения в данном случае.
A>>Суть претензии в том, что в задачи ORM не вхоит организация бизнес транзакций.
kuj>В задачи хранимых процедур организация бизнес-транзакций тоже не входит. Все еще не понимаете?

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

A>>Либо эта задача решается в лоб, что приводит к написания большого объёма достаточно сложного кода, либо сваливается на БД в которых транзакции уже есть.
kuj>(вздыхая) почитайте чтоли на досуге про BTP и как бизнес-транзакции могут существовать без помощи транзакций БД...

А я и не отрицаю что могут. просто это не дёшео. А ты кстати сам давно читал? А то весь дня два как про бизнес-транзакции знаешь. И когда только успел? Молодец!

Здравствуйте, adontz, Вы писали:

C>>В конце регистрации — коммит всей накопленой информации в базу в одной транзакции. Тогда у нас гарантировано система всегда будет в целостном состоянии — если у нас во время коммита в сервер приложений попадет метеорит, то транзакция в базе данных потом спокойно откатится по таймауту. С точки зрения остальных клиентов все изменения тоже атомарны.

A>вот об том и речь., что ты не в состоянии дёшево отганизовать транзакции вне БД и делаешь две операции CreateUserWithCar и CreateCar имеющие много общего кода (копи-паст, если по простому).

Я Вам уже говорил. И еще раз повторю. Ликбез: все транзакции БД выполняются ТОЛЬКО в БД. Понятие бизнес-транзакция высокоуровневое и оно никоим образом не завязано на конкретной БД с т.з. бизнес-логики.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>>>Объясни как и не хами. Я привёл несколько сценариев когда обеспечивает. Аргументированно опровергни.
kuj>>Что опровергнуть? Что NHibernate уступает ХП в плане управления транзакциями БД? Вам разные люди твердят, что ничем не уступает, и напротив предоставляет дополнительный инструментарий, а Вы продолжаете упорствовать?
kuj>>Читайте документацию по NHibernate (Hibernate), ADO.NET (JDBC) пока не поймете этого. Заниматься восполнением пробелов в вашем образовании я не собираюсь.

A>Опять нет ответа, одно хамство. Это уже закономерность какая-то...

Вам уже сто раз ответили при чем совершенно разные люди. Разуйте глаза и закройте рот.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>Я Вам уже говорил. И еще раз повторю. Ликбез: все транзакции БД выполняются ТОЛЬКО в БД. Понятие бизнес-транзакция высокоуровневое и оно никоим образом не завязано на конкретной БД с т.з. бизнес-логики.

Вот именно. Только организовать эти транзакции вне БД тебе слишком сложно и проще засунуть в БД всё что туда вообще можно засунуть.
Ты сам сказал

Сценарий, приведенный вами, как-раз элементарно решается средствами NHibernate — открыв транзакцию БД в начале, и закоммитив ее после добавления автомобиля.

Теперь давай тоже самое, но без "открыв транзакцию БД в начале", потому что, как ты правильно заметил, "бизнес-транзакция высокоуровневое и оно никоим образом не завязано на конкретной БД".

Здравствуйте, kuj, Вы писали:

kuj> Разуйте глаза и закройте рот.

То есть ответа ты не знаешь, да?

Здравствуйте, adontz, Вы писали:

kuj>>CreateUser+CreateCar+CommitTransaction+SendSmsToAdmin. CommitTransaction все накопленные в сессии данные сбрасывает внутри одной транзакции в базу.
kuj>>Вы все еще не понимаете?

A>Это ты не понимаешь, что если SMS не отослался, то создание юзера надо откатить.
A>CreateUser+CreateCar+SendSmsToAdmin+CommitTransaction

A>БД не пуп земли.
В таком случае Вам никто и ни что не поможет, т.к. нельзя сделать rollback уже отправленной SMS. Единственное, что приходит на ум добавить это добавить информацию по SMS в специальную таблицу в БД, с которой работает отдельный сервис в режиме чтения, рассылая эти SMS.

A>>>Время жизни не имеет абсолютно никакого принципиального значения в данном случае.
A>>>Суть претензии в том, что в задачи ORM не вхоит организация бизнес транзакций.
------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
kuj>>В задачи хранимых процедур организация бизнес-транзакций тоже не входит. Все еще не понимаете?

A>В задачи БД входят транзакции которые используют для транзакционирования логики не имеющей к БД прямого отношения. Это факт, ты сам только что так предлагал.
---^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Мда... клиника. Вы сами себе противоречите. Определитесь уж: входит или не входит. А заодно разберитесь с понятием бизнес-транзакция и поднапрягите извилину и ответьте на вопрос: должен ли DAL знать что-то о бизнес-логике или не должен.

Намек: транзакции СУБД != бизнес-транзакции. Это понятия совершенно разные и их даже сравнивать нельзя.

A>>>Либо эта задача решается в лоб, что приводит к написания большого объёма достаточно сложного кода, либо сваливается на БД в которых транзакции уже есть.
kuj>>(вздыхая) почитайте чтоли на досуге про BTP и как бизнес-транзакции могут существовать без помощи транзакций БД...

A>А я и не отрицаю что могут. просто это не дёшео. А ты кстати сам давно читал? А то весь дня два как про бизнес-транзакции знаешь. И когда только успел? Молодец!

Н-да, смешную вы там травку курите. Поделитесь?

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>Я Вам уже говорил. И еще раз повторю. Ликбез: все транзакции БД выполняются ТОЛЬКО в БД. Понятие бизнес-транзакция высокоуровневое и оно никоим образом не завязано на конкретной БД с т.з. бизнес-логики.

A>Вот именно. Только организовать эти транзакции вне БД тебе слишком сложно и проще засунуть в БД всё что туда вообще можно засунуть.
A>Ты сам сказал
A>

A>Сценарий, приведенный вами, как-раз элементарно решается средствами NHibernate — открыв транзакцию БД в начале, и закоммитив ее после добавления автомобиля.

A>Теперь давай тоже самое, но без "открыв транзакцию БД в начале", потому что, как ты правильно заметил, "бизнес-транзакция высокоуровневое и оно никоим образом не завязано на конкретной БД".

Речь о транзакциях С У Б Д. Читаем по буквам медленно и вслух, и повторяем до просветления.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>В таком случае Вам никто и ни что не поможет, т.к. нельзя сделать rollback уже отправленной SMS. Единственное, что приходит на ум добавить это добавить информацию по SMS в специальную таблицу в БД, с которой работает отдельный сервис в режиме чтения, рассылая эти SMS.

Речь о другом. Если мне не удалось отослать SMS, то надо откатить создание пользователя. Понятно, что SMS это просто пример out-of-database action.

A>>>>Время жизни не имеет абсолютно никакого принципиального значения в данном случае.
A>>>>Суть претензии в том, что в задачи ORM не вхоит организация бизнес транзакций.
kuj>------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
kuj>>>В задачи хранимых процедур организация бизнес-транзакций тоже не входит. Все еще не понимаете?

A>>В задачи БД входят транзакции которые используют для транзакционирования логики не имеющей к БД прямого отношения. Это факт, ты сам только что так предлагал.
kuj>---^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

kuj>Мда... клиника. Вы сами себе противоречите. Определитесь уж: входит или не входит. А заодно разберитесь с понятием бизнес-транзакция и поднапрягите извилину и ответьте на вопрос: должен ли DAL знать что-то о бизнес-логике или не должен.

Не хами.

kuj>Намек: транзакции СУБД != бизнес-транзакции. Это понятия совершенно разные и их даже сравнивать нельзя.

Я с этим согласен, но ты потом приводишь решения, которые противоречат твоим же словам. Решение основывающиеся именно на транзакциях БД.

Кстати ты почему-то всё время акцентируешь на возможности откатить. В то же время уровень изоляции не менее важен. Вот пример задачи на котрой это отчётливее проявляется.
Есть табличка Users. После добавления туда пользователя с заданным логином (добавляем для резервации логина, например) распечатывается контракт. После подписывания контракта лист сканируется и загружается в БД. Теперь, внимание, условие: пользователи, не подписавшие контракт, не должны светится в списке пользователей нигде. Подобная бизнес-транзакция может занимать минут 30, а то и пару суток. Решать эту задачу методом "открыв транзакцию БД в начале" не выйдет.

Здравствуйте, kuj, Вы писали:

kuj>Речь о транзакциях С У Б Д. Читаем по буквам медленно и вслух, и повторяем до просветления.

Это не так, речь как раз о бизнес-транзакциях. Я описал сценарий бизнес-транзакции в этом сообщении
http://www.rsdn.ru/forum/message/2674922.1.aspx
его то мы и обсуждали в дальнейшем.

Cyberax свёл всё к БД-транзакциям
http://www.rsdn.ru/forum/message/2674954.1.aspx

Я на это указал
http://www.rsdn.ru/forum/message/2674961.1.aspx

Ты зачем-то заявил, что бизнес-транзакция и бд-транзакция разные вещи. Ну да ладно, сказал и чёрт с ним.
http://www.rsdn.ru/forum/message/2674965.1.aspx

Я попросил предоставить реализацию бизнес-транзакции без использования БД-транзакции
http://www.rsdn.ru/forum/message/2674968.1.aspx

И тут ты вдруг заявляешь что мы не обсуждаем бизнес-транзакции. И где логика в твоих собщениях?

Здравствуйте, adontz, Вы писали:

kuj>>В таком случае Вам никто и ни что не поможет, т.к. нельзя сделать rollback уже отправленной SMS. Единственное, что приходит на ум добавить это добавить информацию по SMS в специальную таблицу в БД, с которой работает отдельный сервис в режиме чтения, рассылая эти SMS.

A>Речь о другом. Если мне не удалось отослать SMS, то надо откатить создание пользователя. Понятно, что SMS это просто пример out-of-database action.
В таком случае (когда Вам НЕ надо откатывать SendSMS) как раз все очень просто — коммит делается после SendSMS в том случае, если она вернула true (или еще как-то уведомила).

kuj>>Намек: транзакции СУБД != бизнес-транзакции. Это понятия совершенно разные и их даже сравнивать нельзя.

A>Я с этим согласен, но ты потом приводишь решения, которые противоречат твоим же словам. Решение основывающиеся именно на транзакциях БД.
Еще раз повторяю: бизнес-транзакция понятие высокоуровневое и физически в программе их можно оформлять разными способами — транзакции БД это лишь один из способов. С этим способом ORM справляются как минимум не хуже ХП, а скорее даже лучше благодаря более высокоуровневому инструментарию (как-то структурированная обработка исключений или уже упомянутый механизм автоматической оптимистичной блокировки).

A>Кстати ты почему-то всё время акцентируешь на возможности откатить. В то же время уровень изоляции не менее важен. Вот пример задачи на котрой это отчётливее проявляется.
A>Есть табличка Users. После добавления туда пользователя с заданным логином (добавляем для резервации логина, например) распечатывается контракт. После подписывания контракта лист сканируется и загружается в БД. Теперь, внимание, условие: пользователи, не подписавшие контракт, не должны светится в списке пользователей нигде. Подобная бизнес-транзакция может занимать минут 30, а то и пару суток. Решать эту задачу методом "открыв транзакцию БД в начале" не выйдет.
Как же до вас туго доходит... А ведь про этот механизм в Hibernate уже даааааавно Вам говорили. Чем Вы слушали?

http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html#transactions-basics-apptx

Читаем до просветления и завязываем этот спор на ровном месте.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

A>Я попросил предоставить реализацию бизнес-транзакции без использования БД-транзакции
A>http://www.rsdn.ru/forum/message/2674968.1.aspx

A>И тут ты вдруг заявляешь что мы не обсуждаем бизнес-транзакции. И где логика в твоих собщениях?

Логика в теме топика.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>В таком случае (когда Вам НЕ надо откатывать SendSMS) как раз все очень просто — коммит делается после SendSMS в том случае, если она вернула true (или еще как-то уведомила).

Всё не так просто, потому что ты забываешь об изоляции транзакции. Пока не пришло подтверждение доставки SMS, недавно соданные User и Car не должны где-либо фигурировать.

kuj>Еще раз повторяю: бизнес-транзакция понятие высокоуровневое и физически в программе их можно оформлять разными способами — транзакции БД это лишь один из способов.

Да, но других ты не привёл.

kuj>http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html#transactions-basics-apptx
kuj>Читаем до просветления и завязываем этот спор на ровном месте.

Там только try/catch решения. Они не предоставляют изоляции и не защищают от аппаратных сбоев.

Здравствуйте, kuj, Вы писали:

kuj>Логика в теме топика.

То есть по существу вопроса тебе ответить нечего, так и запишем.

Здравствуйте, adontz, Вы писали:

kuj>>В таком случае (когда Вам НЕ надо откатывать SendSMS) как раз все очень просто — коммит делается после SendSMS в том случае, если она вернула true (или еще как-то уведомила).
A>Всё не так просто, потому что ты забываешь об изоляции транзакции. Пока не пришло подтверждение доставки SMS, недавно соданные User и Car не должны где-либо фигурировать.
Я ничего не забываю. Где они по-вашему будут фигурировать, если мы еще не выполняли flush сессии в БД.

kuj>>Еще раз повторяю: бизнес-транзакция понятие высокоуровневое и физически в программе их можно оформлять разными способами — транзакции БД это лишь один из способов.

A>Да, но других ты не привёл.
Привел. Читайте внимательнее.

kuj>>http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html#transactions-basics-apptx
kuj>>Читаем до просветления и завязываем этот спор на ровном месте.

A>Там только try/catch решения. Они не предоставляют изоляции и не защищают от аппаратных сбоев.
Сдаюсь... это клиника. Вы даже не удосуживаетесь почитать, а сразу начинаете какую-то ахинею нести. Клиника.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>Логика в теме топика.

A>То есть по существу вопроса тебе ответить нечего, так и запишем.

Я уже ответил по теме топика при чем в нескольких разных ветках. Если Вы не можете открыть гугл и найти информацию по BTP, то я Вам ничем помочь не могу. Клиника.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

kuj>Я ничего не забываю. Где они по-вашему будут фигурировать, если мы еще не выполняли flush сессии в БД.

ОК пришло подтверждение и тут же вырубилась сеть. Получается SMS есть, а юзера нет. Как ни крути, а целостность ты не обеспечишь.

A>>Да, но других ты не привёл.
kuj>Привел. Читайте внимательнее.

Дай ссылку.

A>>Там только try/catch решения. Они не предоставляют изоляции и не защищают от аппаратных сбоев.
kuj>Сдаюсь... это клиника. Вы даже не удосуживаетесь почитать, а сразу начинаете какую-то ахинею нести. Клиника.

Прочитал и не нашёл. Если это там есть, то процитируй. Не будь голословным и не хами.

Здравствуйте, kuj, Вы писали:

kuj>Я уже ответил по теме топика при чем в нескольких разных ветках. Если Вы не можете открыть гугл и найти информацию по BTP, то я Вам ничем помочь не могу. Клиника.

Я то думал ты что-то действительно знаешь. В гугл послать можно будучи полным дилетантом. Ты сам что-то можешь сказать или только охать будешь?

Здравствуйте, adontz, Вы писали:

kuj>>Я уже ответил по теме топика при чем в нескольких разных ветках. Если Вы не можете открыть гугл и найти информацию по BTP, то я Вам ничем помочь не могу. Клиника.

A>Я то думал ты что-то действительно знаешь. В гугл послать можно будучи полным дилетантом. Ты сам что-то можешь сказать или только охать будешь?

То есть Вы не можете открыть гугл и найти описание BTP (расшифровка аббревиатуры фигурирует как минимум в двух моих сообщения за сегодня) ? м-даа....

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, adontz, Вы писали:

kuj>>Я ничего не забываю. Где они по-вашему будут фигурировать, если мы еще не выполняли flush сессии в БД.

A>ОК пришло подтверждение и тут же вырубилась сеть. Получается SMS есть, а юзера нет. Как ни крути, а целостность ты не обеспечишь.

Н-дааа..... Может Вы бот? Такой непроходимой тупости я еще не встречал... — про SMS я уже говорил и давал пример решения этой проблемы пару сообщений тому назад.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

A>>Я то думал ты что-то действительно знаешь. В гугл послать можно будучи полным дилетантом. Ты сам что-то можешь сказать или только охать будешь?
kuj>То есть Вы не можете открыть гугл и найти описание BTP (расшифровка аббревиатуры фигурирует как минимум в двух моих сообщения за сегодня) ? м-даа....

То есть мне интересно можешь ли ты написать в сообщении что-либо кроме оскорбления оппонента. Например, развёрнутый ответ на поставленный вопросы, а не ссылки на многокилломентровые статьи где якобы есть ответы, хотя их там совсем нет. Даже процитировать нужные отрывки статей на которые ссылаешься, ты не в состоянии.
Гугл такая штука, в нём можно найти всё что угодно. Например я могу в гугле найти стайтов сто одобряющих фашизм. Это же не значит, что фашизм хорошо, не так ли? Аналогично и тут, то что в гугле есть так или иная информация об обработке бизнес-транзакций вовсе не означает что информация верная. Гугл — поисковая система, а не энциклопедия и за корректностью информации никак не следит. Ссылаться в гугл можно когда тебя спрашивают "чему равно число пи?" или "как называется функция открытия файла?". В данном случае ссылка на гугл неадекватна.

Здравствуйте, adontz, Вы писали:

A>>>Я то думал ты что-то действительно знаешь. В гугл послать можно будучи полным дилетантом. Ты сам что-то можешь сказать или только охать будешь?
kuj>>То есть Вы не можете открыть гугл и найти описание BTP (расшифровка аббревиатуры фигурирует как минимум в двух моих сообщения за сегодня) ? м-даа....

A>То есть мне интересно можешь ли ты написать в сообщении что-либо кроме оскорбления оппонента. Например, развёрнутый ответ на поставленный вопросы, а не ссылки на многокилломентровые статьи где якобы есть ответы, хотя их там совсем нет. Даже процитировать нужные отрывки статей на которые ссылаешься, ты не в состоянии.
A>Гугл такая штука, в нём можно найти всё что угодно. Например я могу в гугле найти стайтов сто одобряющих фашизм. Это же не значит, что фашизм хорошо, не так ли? Аналогично и тут, то что в гугле есть так или иная информация об обработке бизнес-транзакций вовсе не означает что информация верная. Гугл — поисковая система, а не энциклопедия и за корректностью информации никак не следит. Ссылаться в гугл можно когда тебя спрашивают "чему равно число пи?" или "как называется функция открытия файла?". В данном случае ссылка на гугл неадекватна.

Я понял. Вы бот. Флейм-бот. Нормальный человек в здравом уме такой ахинеи нести не может. Я прекращаю этот спор в одностороннем порядке.

Горбатого могила выправит.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, kuj, Вы писали:

A>>ОК пришло подтверждение и тут же вырубилась сеть. Получается SMS есть, а юзера нет. Как ни крути, а целостность ты не обеспечишь.
kuj>Н-дааа..... Может Вы бот? Такой непроходимой тупости я еще не встречал... — про SMS я уже говорил и давал пример решения этой проблемы пару сообщений тому назад.

Не хами.

Вот хронология:
1. Запрос на создание пользователя.
(сбой в данный период не приводит к негативным последствиям)
2. Сохранение запроса
(сбой в данный период не приводит к негативным последствиям)
3. Запрос на создание машины
(сбой в данный период не приводит к негативным последствиям)
4. Сохранение запроса
(сбой в данный период не приводит к негативным последствиям)
5. Отсылка SMS
(сбой в данный период приводит к откату)
6. Получение подтверждения доставки SMS
(сбой в данный период приводит к несогласованному состоянию БД. SMS доставлен, но данные в БД не записаны)
7. Запись ранее сохранённых запросов.

Какие у тебя есть возражения по существу?

Здравствуйте, kuj, Вы писали:

kuj>Я понял. Вы бот. Флейм-бот. Нормальный человек в здравом уме такой ахинеи нести не может. Я прекращаю этот спор в одностороннем порядке.
kuj>Горбатого могила выправит.

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

Здесь уже было одно предупредиле о форме ведения дискуссии. Это последнее китайское.

Неясность изложения обычно происходит от путаницы в мыслях.

Здравствуйте, adontz, Вы писали:

C>>В конце регистрации — коммит всей накопленой информации в базу в одной транзакции. Тогда у нас гарантировано система всегда будет в целостном состоянии — если у нас во время коммита в сервер приложений попадет метеорит, то транзакция в базе данных потом спокойно откатится по таймауту. С точки зрения остальных клиентов все изменения тоже атомарны.
A>вот об том и речь., что ты не в состоянии дёшево отганизовать транзакции вне БД и делаешь две операции CreateUserWithCar и CreateCar имеющие много общего кода (копи-паст, если по простому).
Слушай, ты читаешь что тебе пишут вообще? Транзакции вне БД мне нафиг организовывать не нужно — в процессе регистрации в базу данных ничего не пишется.

Единственный момент, когда идет запись — это при завершении регистрации, когда у нас уже есть данные пользователя и данные хотя бы одного автомобиля. В виде псевдокода это можно предствить так:

Transaction trans=...;
trans.begin();
Session sess=getSessionWithPendingObjects();
sess.flush(); //Сбрасываем накопленые изменения.
trans.commit();

В результате, все операции типа CreateUser/CreateCar и им подобные выполняются вместе в одной транзакции.

Теперь понял?

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kuj, Вы писали:

A>>>Ну у Синклера же был пример в соседней ветке про CreateUser, CreateSite и CreateUserWithSite. Найди и почитай. Фактически да, бизнес-транзакция оказалась в БД, хотя там ей, конечно, делать нечего. Это именно из-за невозможности (огромной трудоёмкости) сделать устойчивую к отказам оборудования транзакцию выше уровня DAL.
kuj>>Чушь.

A>Если не трудно, вырази свою мысль чуть подробнее. Например как бы ты решал эту задачу (бизнес-транзакция CreateUser+CreateSite) с учётом возможных аппаратных сбоев.
Вам уже пора сделать тему adontz vs kuj

, а то зафлудили всю ветку, читать уже невозможно.

Здравствуйте, Aviator, Вы писали:

A>Вам уже пора сделать тему adontz vs kuj

, а то зафлудили всю ветку, читать уже невозможно.

Пусть в привате срутся.

Здравствуйте, Cyberax, Вы писали:

C>Слушай, ты читаешь что тебе пишут вообще? Транзакции вне БД мне нафиг организовывать не нужно — в процессе регистрации в базу данных ничего не пишется.
C>Теперь понял?

Сам ты не читаешь

Здравствуйте, Светлояр, Вы писали:

С>Пусть в привате срутся.

Зачем же ущемлять права эксгибиционистов?

Здравствуйте, adontz, Вы писали:

C>>Слушай, ты читаешь что тебе пишут вообще? Транзакции вне БД мне нафиг организовывать не нужно — в процессе регистрации в базу данных ничего не пишется.
C>>Теперь понял?
A>Сам ты не читаешь

Я уже сказал, что этот примитивный случай не интересен, поскольку теряется общность поставновки задачи. У тебя всё в БД, поэтому ты можешь обойтись транзакциями уровня БД. В задаче с отсылкой SMS это не так.
А я всегда пишу так, что я могу обойтись только транзакциями БД для сохранения целостности, в том числе, и специально дизайня для этого схему. Пока что везде получалось без проблем. БД очень хорошо умеют сохранять целостность данных — так что пусть этим и занимаются.

Например, для обеспечения бизнес-правила "у пользователя всегда должна быть машина" можно сделать два типа пользователей: prospect и active (в простейшем случае, добавив флаг 'registration_completed' в табличку пользователя). Далее дизайним приложение так, чтобы для незавершенных пользователей были доступны только формы редактирования его машин. В качестве дополнительной проверки — вешаем check/trigger, проверяющий инвариант "registration_completed xor empty(user.cars)".

В частности, если мне нужно использовать два разных транзакционных ресурса — то я буду использовать распределенные транзакции (XA-транзакции). Причем в XA-транзакции можно добавить один не-XA-ресурс без нарушения гарантий (он делает решающий коммит в конце фазы PREPARE). В твоем случае, скорее всего, таким ресурсом будет посылатель SMS.

Здравствуйте, adontz, Вы писали:

Как бы это сделал я.

A>Вот хронология:
--- Начинаем XA-транзакцию ---
A>1. Запрос на создание пользователя.
A>(сбой в данный период не приводит к негативным последствиям)
A>2. Сохранение запроса
A>(сбой в данный период не приводит к негативным последствиям)
A>3. Запрос на создание машины
A>(сбой в данный период не приводит к негативным последствиям)
A>4. Сохранение запроса
A>(сбой в данный период не приводит к негативным последствиям)
4.5 Добавляем SMS-сообщение в очередь сообщений.
--- Коммитим XA-транзакцию. Выполняется фаза PREPARE для базы данных, в случае ошибки откатываемся ---

Выполняется В САМОМ КОНЦЕ фазы PREPARE:
A>5. Отсылка SMS
A>(сбой в данный период приводит к откату)
A>6. Получение подтверждения доставки SMS
A>(сбой в данный период приводит к несогласованному состоянию БД. SMS доставлен, но данные в БД не записаны)
Сбой в посылку SMS в данный момент приведет к откату XA-транзакции (база данных еще находится в стадии PREPARE).

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

Здравствуйте, Cyberax, Вы писали:

C>А я всегда пишу так, что я могу обойтись только транзакциями БД для сохранения целостности, в том числе, и специально дизайня для этого схему. Пока что везде получалось без проблем. БД очень хорошо умеют сохранять целостность данных — так что пусть этим и занимаются.

Правильно. Об этом я и говорил. Транзакции в БД такие хорошие, что люди всеми правдами и неправдами пытаются использовать именно их, а не писать свои.

Однако этот путьн е без проблем. Во-первых, хотя для большинства приложений это и работает, всё же бывают ситуации когда действие ну никак в БД не впихивается. во-вторых, транзакции это ещё и уровень изоляции. Не зная потрохов SQL запросов можно запросто словить дедлок указав изначально слишком низкий уровень изоляции. Указав слишком высокий получишь starvation. вобщем свои проблемы, помимо чисто идеологических, у этого подхода тоже есть.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, adontz, Вы писали:
C>Как бы это сделал я.

Что такое у тебя XA-транзакция?

Здравствуйте, adontz, Вы писали:

C>>Здравствуйте, adontz, Вы писали:
C>>Как бы это сделал я.
A>Что такое у тебя XA-транзакция?
Распределенные транзакции, соответствующие стандарту X/Open XA (я без понятия почему он называется XA). Почитать можно тут: http://en.wikipedia.org/wiki/Two-phase_commit

Здравствуйте, adontz, Вы писали:

C>>А я всегда пишу так, что я могу обойтись только транзакциями БД для сохранения целостности, в том числе, и специально дизайня для этого схему. Пока что везде получалось без проблем. БД очень хорошо умеют сохранять целостность данных — так что пусть этим и занимаются.
A>Правильно. Об этом я и говорил. Транзакции в БД такие хорошие, что люди всеми правдами и неправдами пытаются использовать именно их, а не писать свои.
Именно.

A>Однако этот путьн е без проблем. Во-первых, хотя для большинства приложений это и работает, всё же бывают ситуации когда действие ну никак в БД не впихивается.
Мне пока не попадались. Хотя в некоторых случаях действительно приходилось делать приседания.

Хотя, в принципе, и для таких случаев есть всякие BPMы (Business Process Manager'ы) с поддержкой компенсирующих транзакций.

A>во-вторых, транзакции это ещё и уровень изоляции. Не зная потрохов SQL запросов можно запросто словить дедлок указав изначально слишком низкий уровень изоляции. Указав слишком высокий получишь starvation. вобщем свои проблемы, помимо чисто идеологических, у этого подхода тоже есть.
У меня ни разу еще не появлялось надобности в изоляции больше READ COMMITED. А дедлоки очень эффективно обходятся с помощью оптимистического версирования (поэтому оно мне так и нравится).

Здравствуйте, Cyberax, Вы писали:

C>>>Как бы это сделал я.
A>>Что такое у тебя XA-транзакция?
C>Распределенные транзакции, соответствующие стандарту X/Open XA (я без понятия почему он называется XA). Почитать можно тут: http://en.wikipedia.org/wiki/Two-phase_commit

Оно конечно здорово, но вроде кластерная штукенция. То есть, скажем, на SQL Server Express (Standard) этого нет и не будет если я правильно понял что это и зачем.

Здравствуйте, adontz, Вы писали:

A>>>Что такое у тебя XA-транзакция?
C>>Распределенные транзакции, соответствующие стандарту X/Open XA (я без понятия почему он называется XA). Почитать можно тут: http://en.wikipedia.org/wiki/Two-phase_commit
A>Оно конечно здорово, но вроде кластерная штукенция. То есть, скажем, на SQL Server Express (Standard) этого нет и не будет если я правильно понял что это и зачем.
Нет, тут слово "распределенная" значит, что в транзакции участвуют несколько источников (не обязательно распределенных). В Windows в качестве координатора обычно используется MS DTC, который вроде даже в SQL SE поддерживается.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, nicolas1, Вы писали:

N>>Какие есть ORM для С++, пригодные для использования? В частности интересует поддерживающие sqlite.

IT>Зачем ORM для C++? Добрался до буфера резалтсета, преобразовал его к нужной структуре и готово.

Подробнее можно? Т.е. sql запрос к БД, для отновительной простоты, можно оформить его в виде паттерна "active record" для удобства, и разбираем резалт?
Для операций вставки, select, редактирования и удаление все тривиально, но как решается вопрос наследования, отношение one-to-many, many-to-many. Наверно, как раз для этого ORM и существует? Интересует именно объектный доступ к реляционной БД.

Как на практике решается вопрос объектного доступа к реляционной БД в с++: пишется что-то свое, просто мапить объекты на файлы, используется DAL-подход (active record) или что-то еще. Конкретно в случае когда надо, embedded бд, типа sqlite, записей до 500000, наследование, отношения one-to-many, many-to-many (связи между объектами).

Здравствуйте, Cyberax, Вы писали:
S>>Далее, в стоимость коммита начинает входить повторное чтение всех прочитанных в транзакции данных.
C>Нет, стандартный прием для версирования: "UPDATE ... SET ... WHERE id=? AND version=?". Если этот оператор вернет 0 (ни одного ряда не обновлено) — то значит у нас оптимистическая ошибка. Можно это сделать и batch'ем для нескольких обновлений.
Эта реализация оптимистической блокировки примерно соответствует уровню read committed. К сожалению, если требуется хотя бы repeatable read, стоимость оптимизма становится значительно выше и такой наивный подход работать не будет.

C>Обычно для сервисов нужно минимизировать длину. Кроме того, тут у нас затраты на память будут на стороне клиента, а не сервера. Так что если он решит похулиганить — то ССЗБ.
Да ну? Не может такого быть. Затраты будут ровно на стороне сервера, т.к. ему нужно накапливать изменения, пока с клиента не придет коммит. Клиент может позволить себе забыть о произведенных действиях сразу после того, как он обратился к серверу.

C>Так пусть себе DDoSит себя — отъест свои соединия и отвалится. На остальных клиентов влиять не будет.
Вопрос интересный.

C>Так ее надо один раз сделать — и она будет решать. Мы вот себе сделали такую неплохую инфраструктуру, в которой есть фичи, которых нет ни в одном существующем протоколе remoting'а

S>>Совершенно верно. В идеале, вместо SQL был бы нормальный язык высокого уровня, который бы не приносил такого страшного performance penalty на не-SQL операциях.
C>Еще он сам по себе слишком жуткий по сравнению даже с VB.
Это да.

S>>Вообще, курсоры в T-SQL, к примеру, так плохи не потому, что вообще плохи, а потому, что код курсора чудовищно медленно интерпретируется.
S>>Если бы код компилировался в нативную программу, то особой разницы в стейтменте с UDF и курсоре не было бы.
C>Ну это возможно, во всяких там DB2 и прочих — там процедуры компилируются в С, а потом и в машинный код.
Интересно бы глянуть на их данные по производительности.

S>>Хочется чего-то более простого; причем очевидный способ — это именно скармливать запросы целиком. Вот HTTP построен именно по этой схеме, и он прямо-таки фантастически удачен.
C>Тогда будет ваша проблема с кучей мелких тривиальных операций.
Ее можно решить, введя в протокол понятие группы операций, запрашиваемых одним запросом.
C>Кстати, и HTTP не так уж удачен для многих задач.
Да. Хотя вон народ по нему и видео стримает...

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, adontz, Вы писали:
A>Вызываешь
A>BeginTransaction()
A>User user = CreateUser(...)
A>CreateSite(user)
A>CommitTransaction()
Непонятно, где я это вызываю. С клиента?

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, adontz, Вы писали:
A>Зачем же ущемлять права эксгибиционистов?

Затем, что эти бывшие гибиционисты ущемляют права других на получение осмысленной информации

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

C>>Нет, стандартный прием для версирования: "UPDATE ... SET ... WHERE id=? AND version=?". Если этот оператор вернет 0 (ни одного ряда не обновлено) — то значит у нас оптимистическая ошибка. Можно это сделать и batch'ем для нескольких обновлений.
S>Эта реализация оптимистической блокировки примерно соответствует уровню read committed. К сожалению, если требуется хотя бы repeatable read, стоимость оптимизма становится значительно выше и такой наивный подход работать не будет.
Мне REPEATABLE READ ни разу еще не понадобился. Хватает либо READ COMMITED или сразу же SERIALIZABLE. Тем более, что REPEATABLE READ многие базы поддерживают очень плохо (или вообще не поддерживают, как PostgreSQL).

C>>Обычно для сервисов нужно минимизировать длину. Кроме того, тут у нас затраты на память будут на стороне клиента, а не сервера. Так что если он решит похулиганить — то ССЗБ.
S>Да ну? Не может такого быть. Затраты будут ровно на стороне сервера, т.к. ему нужно накапливать изменения, пока с клиента не придет коммит. Клиент может позволить себе забыть о произведенных действиях сразу после того, как он обратился к серверу.
На сервере нам достаточно накапливать только обновляемые объекты. Так что это ничем не отличается от ситуации, когда клиент пошлет на сервер в виде SQL-скрипта пару сотен тысяч команд insert/update.

S>>>Вообще, курсоры в T-SQL, к примеру, так плохи не потому, что вообще плохи, а потому, что код курсора чудовищно медленно интерпретируется.
S>>>Если бы код компилировался в нативную программу, то особой разницы в стейтменте с UDF и курсоре не было бы.
C>>Ну это возможно, во всяких там DB2 и прочих — там процедуры компилируются в С, а потом и в машинный код.
S>Интересно бы глянуть на их данные по производительности.
Очень быстрая, что неудивительно. Хотя сама DB2 — слишком уж монструозная вещь.

S>>>Хочется чего-то более простого; причем очевидный способ — это именно скармливать запросы целиком. Вот HTTP построен именно по этой схеме, и он прямо-таки фантастически удачен.
C>>Тогда будет ваша проблема с кучей мелких тривиальных операций.
S>Ее можно решить, введя в протокол понятие группы операций, запрашиваемых одним запросом.
Это тоже далеко не простое решение будет.

	От:	Kazna4ey
	Дата:	22.09.07 10:08
	Оценка:	4 (1) -1

	От:	Gollum
	Дата:	22.09.07 10:14
	Оценка:

От:	adontz	http://adontz.wordpress.com/
Дата:	22.09.07 13:30
Оценка:

	От:	Kazna4ey
	Дата:	22.09.07 13:34
	Оценка:

	От:	Aviator
	Дата:	23.09.07 13:49
	Оценка:	+1

От:	Нахлобуч	https://hglabhq.com
Дата:	24.09.07 07:47
Оценка:

	От:	AndrewJD
	Дата:	24.09.07 10:00
	Оценка:	40 (2) -1

От:	Sinclair	https://github.com/evilguest/
Дата:	24.09.07 10:57
Оценка:	1 (1) +1

От:	MozgC	http://nightcoder.livejournal.com
Дата:	24.09.07 19:27
Оценка:	40 (2)

	От:	Светлояр
	Дата:	25.09.07 13:03
	Оценка:

От:	IT	linq2db.com
Дата:	25.09.07 13:05
Оценка:	+2

От:	Dziman	http://github.com/Dziman
Дата:	25.09.07 14:32
Оценка:	+1

От:	Trean	http://axamit.com/
Дата:	26.09.07 12:48
Оценка:	+2

От:	bnk	http://unmanagedvisio.com/
Дата:	26.09.07 13:45
Оценка:

От:	Суслик	http://www.vkkb.ru
Дата:	26.09.07 21:52
Оценка:

	От:	Дмитрий В
	Дата:	27.09.07 20:08
	Оценка:

	От:	Cyberax
	Дата:	28.09.07 07:34
	Оценка:	3 (1) +2

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	03.10.07 16:01
Оценка: