Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Aviator, Вы писали:
A>>>Ну и о чём тогда говорить, если ты не понимаешь что такое БД и зачем она нужна? A>>Я Вас и не заставляю ничего говорить Пишите дальше хранимки, пока ещё есть кого заставить их поддерживать.
A>Пишите дальше SELECT *. Хорошим примером такого способа хранения данных являетс 1С. Вроде бы и в БД всё, но толку от этого никакого. 2процессорный, многоядерный, 4Гб, супер-пупер сервер едва держит 10 клиентских соединений. Вы кажется в эту категорию спешите записаться.
Давно уже применяю ORM чего желал бы и Вашим специалистам.
Re[9]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, AndrewJD, Вы писали:
A>>Интересно, а как у вас организован процесс тестирования? Сидим тыкаем кнопари на формах и ждём что случится? AJD>Как обычно, ежедневные автоматические тесты.
Можно пример?
A>>И вообще, TDD наверно враги прогресса придумали? AJD>TDD — серебрянная пуля?
Посеребренная.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[10]: Оформление работы с БД в корпоративных приложениях -
Это не 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>Если сравнивать тестирование одной и той же задачи, то абсолютно всё равно.
Вы это серьёзно сказали? Вы вообще представляете процесс тестирования на уровне юнит тестов?
Re[11]: Оформление работы с БД в корпоративных приложениях -
A>>просто писать юнит тесты на каком нить c# с заглушками намного проще чем организовывать автоматическое тестирование кода совместно с субд ...
A>Если сравнивать тестирование одной и той же задачи, то абсолютно всё равно.
Вы хоть понимаете о чем говорите??
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[9]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали: A>То что ты сказал не лишено смысла, но к SQL не имеет решительно никакого отношения. Если мостры SQL непредвиденно уходят, это не прослема SQL или ХП. И если они уходят ни оставив ни капли комментариев, документции и т.п. сколько-нибудь полезной тем, кто пришёл им на замену, то это тоже к SQL имеет слабое отношение.
Зато к SQL имеет 100% отношение тот факт, что нет надежного способа определить, сломало ли добавление новой колонки в таблицу какую-то из хранимок или нет. Напомню, что для современных языков высокого уровня есть средства рефакторинга, а для SQL — нету. Так и живут десятилетиями опечатки в именах колонок.
В этом смысле ORM намного лучше. А Linq вообще рвет всех как тазик тузика.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Aviator, Вы писали:
A>>>Я распределить нагрузку на уровне СУБД не судьба? СУБД не кластеризуются? Я же говорю, что ты СУБД никогда и не видел толком... A>>Ага а не приходило в голову, что это не самый гибкий подход к построению распределённого приложения?
A>Как раз это самый гибкий, рабить BL и DAL на разные tier, сделать BL максимально stateless (по крайней мере не кешируещим) и получить щасте. BL для кластеризации начитает хватать обычного NLB, DAL кластеризуется средствами БД. Получаем двухуровневую систему кластеров. В каждый уровень можно досбавлять кластеры по мере необходимости. Весьма гибко.
Это Вам часом не какой-нить распространитель MS SQL сказал?
Re[10]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Sinclair, Вы писали:
S>Зато к SQL имеет 100% отношение тот факт, что нет надежного способа определить, сломало ли добавление новой колонки в таблицу какую-то из хранимок или нет. Напомню, что для современных языков высокого уровня есть средства рефакторинга, а для SQL — нету. Так и живут десятилетиями опечатки в именах колонок.
Здравствуйте, Aviator, Вы писали:
A>>>Что процедурное программирование не менее удобно чем объектное? A>>Зависит от контекста. Иногда объекты ни к селу, ни к городу. В реляционной БД я места ООП не вижу. A>Реляционная БД — это всего лишь хранилище данных, Вы путаете задачу хранения и обработки. Споры вызывает то, что Вы хотите на хранилище возложить ещё и функции обработки. Разработчика бизнес логики в большинстве случев вообще не интересует какая там субд и как она сохраняет, он оперирует доменными объектами.
Вот-вот! Вот этого-то ты и не понимаешь! Народ пишет мегамощные оптимизаторы, реализует сложнешие алгоритмы, а ты телевозир используешь как тумбочку. БД — это НЕ только хранилище данных, но и обработчик низкого уровня.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Aviator, Вы писали:
A>>>>Что процедурное программирование не менее удобно чем объектное? A>>>Зависит от контекста. Иногда объекты ни к селу, ни к городу. В реляционной БД я места ООП не вижу. A>>Реляционная БД — это всего лишь хранилище данных, Вы путаете задачу хранения и обработки. Споры вызывает то, что Вы хотите на хранилище возложить ещё и функции обработки. Разработчика бизнес логики в большинстве случев вообще не интересует какая там субд и как она сохраняет, он оперирует доменными объектами.
A>Вот-вот! Вот этого-то ты и не понимаешь! Народ пишет мегамощные оптимизаторы, реализует сложнешие алгоритмы, а ты телевозир используешь как тумбочку. БД — это НЕ только хранилище данных, но и обработчик низкого уровня.
Если бы Вы такое произнесли в году там 97, это было бы сильное высказывание, а вот в 2007ом стараются максимально абстрагироваться от конкретики СУБД . ORM стновится де факто стандартом разработки корпоративных приложений, linq уже близок к релизному варианту, веб страницы активно пишут на компилируемых яъзыках, скрипты постепенно отмирают...
Re[11]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, 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>>
Re[14]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, Aviator, Вы писали:
A>>Вот-вот! Вот этого-то ты и не понимаешь! Народ пишет мегамощные оптимизаторы, реализует сложнешие алгоритмы, а ты телевозир используешь как тумбочку. БД — это НЕ только хранилище данных, но и обработчик низкого уровня. A>Если бы Вы такое произнесли в году там 97, это было бы сильное высказывание, а вот в 2007ом стараются максимально абстрагироваться от конкретики СУБД . ORM стновится де факто стандартом разработки корпоративных приложений, linq уже близок к релизному варианту, веб страницы активно пишут на компилируемых яъзыках, скрипты постепенно отмирают...
Я так понимаю для тебя SQL и PHP языки одного типа. Печально.
Здравствуйте, 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 позволяет проверить..." В любом случае вероятность уронить производительность системы гораздо выше, когда к БД обращаются как попало.
S>>Зато к SQL имеет 100% отношение тот факт, что нет надежного способа определить, сломало ли добавление новой колонки в таблицу какую-то из хранимок или нет. Напомню, что для современных языков высокого уровня есть средства рефакторинга, а для SQL — нету. Так и живут десятилетиями опечатки в именах колонок.
A>Ты о чём? ХП с опечатками не компилируются
Человек говорит Вам о рефакторинге и об опечатках в колонках. Когда у вас сотни процедур с таким вот именем колонки жестко прописанным в каждой процедуре...
В случае с OR/M, поменяв имя колонки в базе, мне достаточно поменять его всего-лишь раз в файле мэпинга, а Вам придется перелопачивать все сотни процедур да еще и без стредств рефакторинга.
... << RSDN@Home 1.2.0 alpha rev. 746>>
Re[13]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, 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 позволяет проверить..." В любом случае вероятность уронить производительность системы гораздо выше, когда к БД обращаются как попало.
Что понимается по как попало объясните пожалуйста, а то я начинаю терять нить изложения.
Re[12]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, adontz, Вы писали:
S>>>Зато к SQL имеет 100% отношение тот факт, что нет надежного способа определить, сломало ли добавление новой колонки в таблицу какую-то из хранимок или нет. Напомню, что для современных языков высокого уровня есть средства рефакторинга, а для SQL — нету. Так и живут десятилетиями опечатки в именах колонок.
A>>Ты о чём? ХП с опечатками не компилируются
kuj>Человек говорит Вам о рефакторинге и об опечатках в колонках. Когда у вас сотни процедур с таким вот именем колонки жестко прописанным в каждой процедуре... kuj>В случае с OR/M, поменяв имя колонки в базе, мне достаточно поменять его всего-лишь раз в файле мэпинга, а Вам придется перелопачивать все сотни процедур да еще и без стредств рефакторинга.
Подозреваю, что человек не знает что такое рефакторинг так что Ваш довод для него пустой звук .
Re[13]: Оформление работы с БД в корпоративных приложениях -
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>>
Re[11]: Оформление работы с БД в корпоративных приложениях -
Здравствуйте, 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>>
Re[17]: Оформление работы с БД в корпоративных приложениях -
A>>>Ну и о чём тогда говорить, если ты не понимаешь что такое БД и зачем она нужна? A>>Я Вас и не заставляю ничего говорить Пишите дальше хранимки, пока ещё есть кого заставить их поддерживать.
A>Пишите дальше SELECT *.
Наоборот тут речь о том, чтоб генерацией SQL-запросов занимался Hibernate (или т.п.), который прекрасно с этой задачей справляется, и в запросах, генерируемых Hibernate, Вы не увидете "*".
A> Хорошим примером такого способа хранения данных являетс 1С. Вроде бы и в БД всё, но толку от этого никакого. 2процессорный, многоядерный, 4Гб, супер-пупер сервер едва держит 10 клиентских соединений. Вы кажется в эту категорию спешите записаться.
Очень удачно Вы привели 1С, как пример "неудачной системы".
Называется: ежики плакали, кололись, но продолжали жрать кактус.
Пишите дальше хранимки, пока ещё есть кого заставить их поддерживать
... 
