Здравствуйте, vdimas, Вы писали:
V>Для расширения кругозора — в некоторых базах их называют "сохранённые запросы с параметрами". Мне тоже смешно.
Что за чудо природы (приветствуются ссылки)? Это случаем не прекомпилированные запросы?
Кстати, для расширения кругозора... Параметризация и прекомпиляция (равно как и сохранение запросов где угодно) — это особенности конкретного API конкретного сервера. В SQL все это не входит. Ну, и параметризация или компиляция не оказывает никакого влияния на типизированность SQL.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>Какая прелесть "сохранённые запросы"?! Сам придумал, сам обсуждает.
V>Не обязательно блистать невежеством, в один базах это называется "view", в других "сохранённый запрос".
О как? И ссылки приведешь?
А view — название стандартизированное.
Ну, да ладно. Считай вывернулся.
Какое отношение представления имеют к нетипизированности SQL?
VD>>По-твоему зачем в таблицах описываются типы данных колонок?
V>Покажи мне типы тут: V>
V>select a+1 a1, b from c
V>
V>Тип a1 какой? V>Число, строка, дата?
Залезь в описание таблицы "c" и посмотри тип колонки "a1". select — это банальная проекция.
C# ты ведь знаешь? Вот тебе аналогичный пример на C#:
var x = c.a1;
какой тут тип у "x"?
Чтобы ответить на этот вопрос нужно знать тип поля a1. Это называется примитивным выводом типа.
Любой SQL-сервер умеет это делать на раз.
V>Как насчёт того, что в джоинах по некоей паре полей мы можем (по ошибке или намеренно) связываться даже в случае несовместимых типов этих полей (например, строки и числа)?
Это называется вольное обращение с автоматическим приведением типов. Встречается сплошь и рядом в весьма типизированных языках. Например, в Васике. Да что там Васик? Шарп и тот этим не брезгует, хотя и более аккуратно.
SQL-ем это не прудсматривается — это поведение конкретного сервера.
Собственно к делу это тоже не относится. Ведь кто-то утверждал (серьезно так), что SQL, дескать, динамически типизирован. Причем (хотя причем тут это вообще не ясно) не только не только MS SQL, практически у всех популярных СУБД.
Вот я и хочу увидеть обоснование этой гипотезы. Если оно будет, в чем я сильно сомневаюсь, то можно будет обсудить остальные выводы.
VD>>Статическая типизация — это когда типы выражений известны до выполнения. И для SQL-я это всегда так.
V>И что есть "выполнение" для СУБД?
Тебе и такие вещи нужно разжёвывать?
ОК. Выполнение — это когда серверу делают запрос и он возвращает в ответ результирующее множество.
V> Выполнение конкретного запроса? А как насчёт статической проверки всего вообще до запуска любых запросов, т.е. до поднятия базы?
А, никак. Нет никакого "всего". То как работает конкретный сервер отдается на его усмотрение.
V>Как ни крути, а нарваться на несоответствие типов при некоем касте мы можем зачастую только в "run-time", в случае везения — на юнит тестах.
Ну, вам магам виднее.
Если серьезно, то приведение типов — это операция которая и в статически-типизированных языках может привести к ошибкам времени выполнения.
Вот простой пример:
object x = 1;
string y = (string)x;
В природе есть языки которые не допускают опасных приведений типов, но пользоваться ими крайне не просто.
Опять же к делу это отношения не имеет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
На MS Access, например?
VD>Залезь в описание таблицы "c" и посмотри тип колонки "a1". select — это банальная проекция. VD>C# ты ведь знаешь? Вот тебе аналогичный пример на C#: VD>
VD>var x = c.a1;
VD>
VD>какой тут тип у "x"? VD>Чтобы ответить на этот вопрос нужно знать тип поля a1. Это называется примитивным выводом типа. VD>Любой SQL-сервер умеет это делать на раз.
О нет, мы можем изменить тип колонки в "с" и запустить запрос заново. И тут я вижу сценарий, обычный для нетипизированных скриптов, откуда ты статическую типизацию берешь?
V>>Как насчёт того, что в джоинах по некоей паре полей мы можем (по ошибке или намеренно) связываться даже в случае несовместимых типов этих полей (например, строки и числа)?
VD>Это называется вольное обращение с автоматическим приведением типов. Встречается сплошь и рядом в весьма типизированных языках. Например, в Васике.
Это называется динамическая типизация, вообще-то. VB это умеет без явной аннотации.
VD>Собственно к делу это тоже не относится. Ведь кто-то утверждал (серьезно так), что SQL, дескать, динамически типизирован. Причем (хотя причем тут это вообще не ясно) не только не только MS SQL, практически у всех популярных СУБД.
Да, и привел пример union, где можно свалить в одну колонку разнотипные данные из разных таблиц, причем итоговый тип может зависеть от того, какая таблица идёт первая. Что не так сказал?
VD>Вот я и хочу увидеть обоснование этой гипотезы. Если оно будет, в чем я сильно сомневаюсь, то можно будет обсудить остальные выводы.
Привёл пример из уровня "0" использования БД, там обосновывать нечего.
V>> Выполнение конкретного запроса? А как насчёт статической проверки всего вообще до запуска любых запросов, т.е. до поднятия базы?
VD>А, никак. Нет никакого "всего". То как работает конкретный сервер отдается на его усмотрение.
Вот, и я всего лишь предложил перенять практику некоторых ООБД-серваков, которые проверяют целостность по типам перед запуском. Теперь понятно, что имелось ввиду?
V>>Как ни крути, а нарваться на несоответствие типов при некоем касте мы можем зачастую только в "run-time", в случае везения — на юнит тестах.
VD>Ну, вам магам виднее. VD>Если серьезно, то приведение типов — это операция которая и в статически-типизированных языках может привести к ошибкам времени выполнения. VD>Вот простой пример: VD>
VD>object x = 1;
VD>string y = (string)x;
VD>
Тут тоже классика динамической типизации.
Но вот такой код даже не скомпилится:
int x=1;
string y=(string)x;
Я предлагаю выдавать ошибку и для SQL-серверов перед запуском базы.
---------------
На самом деле мое предложение нелепо по другим причинам: в любой базе можно изменять структуру, создавать/удалять объекты базы прямо по ходу пьесы. Отсюда — динамический характер работы и принципиальная невозможность той самой "статической типизации всего".
Тем не менее, появились возможности задавать табличные ф-ии и прочее в этом направлении, что позволяет уже сегодня обходится в алгоритмах без временных таблиц вообще. А создавать/удалять/изменять структуру объектов, кроме временных, как был моветон во все времена, так и будет. Всвязи с этим и высказался, что неплохо бы пересмотреть самый общий сценарий работы с БД в направлении повышения "статичности по типам", раз мы можем отказаться от временных объектов.
VD>В природе есть языки которые не допускают опасных приведений типов, но пользоваться ими крайне не просто.
Да, хаскелисты тоже так считают. Хотя, полиморфизм по алгебраическим типам — это опять же и снова классика динамической типизации.
Здравствуйте, Lloyd, Вы писали:
L>Это зависит от того, что у вас за клиент. В случае веба click по договору приведет к открытию страницы договора, а на новой странице эта инфорация уже не будет доступна и запрашивать все рано придется.
Ага. Но зачем мне получать объект по id? Я лучше получу всю нужную информацию отображаемую на странице. При этом я не хочу вынимать лишнюю информацию. Запрос же объекта по идентификатору — это неэффективное вынимание данных — запрос данных наобум.
VD>>И select тут будет намного более удобнее. Зачем нам объект? Нам нужно содержимое договора (например).
L>Если схема данных один-в-один соответствует entity, то будет гораздо удобнее. L>Если же DAL занимается каким-нибудь преобразованием из резалтсета в entity, то будет уже не так удобно.
Если нужны преобразования, то не трудно написать функцию. Но зато в 99% случаев ты просто напишешь запрос который вынет те данные которые реально нужны. При этом не прийдется думать о ленивой загрузке, операжающей загрузке, кэшировании и т.п. Ты просто вынешь нужные тебе сейчас данные.
ЗЫ
Более сложный вопрос — это автоматизация записи изменений. Но и тут все решаемо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>На MS Access, например?
Не очень, так как это не SQL-сервер. Но хотя бы на него. А то я почему-то никогда не слышал такой терминалогии. Там запросы назывались просто query.
V>О нет, мы можем изменить тип колонки в "с" и запустить запрос заново.
Измени... запусти. Увидишь, что тип результата изменился.
V>И тут я вижу сценарий, обычный для нетипизированных скриптов, откуда ты статическую типизацию берешь?
Дык есть она там. Типы задаются явно при описании таблиц и выводятся в запросах.
Вот здесь описан макрос Nemerle который во время компиляции выполняет запрос, получает информацию о типах возвращаемых значений и на ее основании генерирует типизированные переменные приемники. Затем он генерирует код связывания.
Заметь. Сам запрос при этом даже не выполняется. Производится только компиляция плана.
Все это было бы не возможно, если бы SQL был не типизированным.
V>>>Как насчёт того, что в джоинах по некоей паре полей мы можем (по ошибке или намеренно) связываться даже в случае несовместимых типов этих полей (например, строки и числа)?
VD>>Это называется вольное обращение с автоматическим приведением типов. Встречается сплошь и рядом в весьма типизированных языках. Например, в Васике.
V>Это называется динамическая типизация, вообще-то. VB это умеет без явной аннотации.
ОК. Убедил — C# динамический язык... ведь приведение типов в нем поддерживается.
V>Да, и привел пример union, где можно свалить в одну колонку разнотипные данные из разных таблиц, причем итоговый тип может зависеть от того, какая таблица идёт первая. Что не так сказал?
Ты себя то слушаешь? Заметь! Тип определяется таблицей которая идет первой. А что же так? А в друг в первой таблице не будет записей? А тип все равно ею определяется.
У вас неувазочка!
VD>>Вот я и хочу увидеть обоснование этой гипотезы. Если оно будет, в чем я сильно сомневаюсь, то можно будет обсудить остальные выводы.
V>Привёл пример из уровня "0" использования БД, там обосновывать нечего.
Ясно. Обоснования не будет. Я так и думал. На сем разреши откланяться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, MozgC, Вы писали:
MC>Скажи, а какой бы подход в работе с БД ты бы выбрал в случае не-MSSQL? Я так понимаю что как раз твой BLT?
На работе я работаю работу на Sybase. Использую понятное дело Булкит. DAL у меня сейчас самый простой слой, требующий минимум поддержки. Но всё же не хватает типизации для полного счастья, поэтому работаю над поддержкой linq в Булките. Там будет и Sybase и MS SQL и ещё минимум штук пять серверов.
Если нам не помогут, то мы тоже никого не пощадим.
V>>И тут я вижу сценарий, обычный для нетипизированных скриптов, откуда ты статическую типизацию берешь?
VD>Дык есть она там. Типы задаются явно при описании таблиц и выводятся в запросах. VD>Вот здесь описан макрос Nemerle который во время компиляции ...
VD>Все это было бы не возможно, если бы SQL был не типизированным.
Эй, сосредоточься!
Ты же сам несколько лет назад объяснял людям, чем отличается статическая типизация, от динамической.
V>>Да, и привел пример union, где можно свалить в одну колонку разнотипные данные из разных таблиц, причем итоговый тип может зависеть от того, какая таблица идёт первая. Что не так сказал?
VD>Ты себя то слушаешь? Заметь! Тип определяется таблицей которая идет первой. А что же так? А в друг в первой таблице не будет записей? А тип все равно ею определяется.
VD>У вас неувазочка!
Я сказал "может зависеть", но реально он может быть чуть ли не произвольным. Более того, такой запрос может проходить, или вываливаться с ошибкой в зависимости от данных (в процессе динамического приведения типов).
VD>Ясно. Обоснования не будет. Я так и думал. На сем разреши откланяться.
Я так и не понял, что требуется обосновать. Обоснование динамической типизации — это наличие самой возможности динамического приведения типов данных. Она есть в большинстве СУБД, и кроме этой динамической типизации другой-то при выборе данных и нет, что при явном, что при неявном касте.
В общем, создай таблицу B, в которой будет один столбец A строкового типа, и напиши запрос:
select A+1 from B
затем внеси различные строковые данные в А (например, которые можно распарсить в целые числа, затем — в дробные, затем — просто набор символов), поиграйся в общем.
Так же поиграй с заменой +1 на +1. , +1.0, +1.00, ...
Результат может зависеть от БД.
Согласно определению разновидностей типизации мы имеем дело с нестрогой + динамической типизацией.
Мой поинт был в том, что строгая + статическая типизация требует отделения процесса разработки от выполнения, т.е. фиксирование типов "до запуска", контроль их соответствия опять же "до запуска" и прочие прелести статической строгой типизации.
Т.е. приведённый выше пример должен выдавать ошибку перед запуском, и требовать явного конвертирования типов. Сейчас же никаких ошибок может и не быть, только на юнит тесты и надежда, как и в любой скриптово-динамической среде.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, MozgC, Вы писали:
MC>>Скажи, а какой бы подход в работе с БД ты бы выбрал в случае не-MSSQL? Я так понимаю что как раз твой BLT?
IT>На работе я работаю работу на Sybase. Использую понятное дело Булкит. DAL у меня сейчас самый простой слой, требующий минимум поддержки. Но всё же не хватает типизации для полного счастья, поэтому работаю над поддержкой linq в Булките. Там будет и Sybase и MS SQL и ещё минимум штук пять серверов.
Здравствуйте, SleepyDrago, Вы писали:
A>>Не без ограничений обошлось, конечно. .. SD>Спасибо. Теперь я примерно представляю ограничения и границы применимости этого подхода.
Угумс. Только надо понимать, что это не ограничения подхода вообще, а только моей реализации. Усложняя генератор можно ограничения снимать.
Здравствуйте, MozgC, Вы писали: MC>Вообще временные таблицы иногда могут помочь упростить запрос.
Они его упрощают ровно потому, что SQL не реализует реляционную алгебру.
Если бы реализовывал, то можно было бы делать как раз так:
-- 1. Define the source for the data
define @storelist table(id int primary key)
if (...)
@storelist = select id from stores where store.city = @city
else if (...)
@storelist = select @storeId
else
@storelist = select id from stores
-- 2. Search for the item availability across all storesselect Availability from StoreItem where itemId = @itemId and storeId in @storelist
То есть мы реально ничего не селектим до момента 2, а всего лишь меняем способ построения списка. Увы — ничего подобного нет. Поэтому приходится принудительно складывать промежуточный результат во временную таблицу (или в табличную переменную — разницы нет). Это мешает серверу самому выбрать план запроса.
Вот как раз поэтому-то линк и рулит, как гидроусилитель БелАЗа.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Tom, Вы писали:
VD>>Там нет ни одного пункта интересующего мнея. BLToolkit меня интересует так же слабо как твои идеи размещения запросов в отдельных файлах. VD>>Лучшим подходом, на мой взгляд, является размещение запросов в виде встроенного (типизированного) DSL внутри кода приложения. Короче говоря подход а-ля linq. Tom>Такой DSL уже есть. Называется TSQL. Можешь пояснить как может выглядеть собственный DSL для работы с данными? Что принципиально будет в нём отличного от того же TSQL?
Самое главное, чего не хватает в T-SQL — возможностей декомпозиции. В принципе, для достижения множественного оргазма почти хватило бы возможности декларировать в спроках что-то типа локальных view, и редефайнить их по мере необходимости. То есть реляция должна бы стать first-class object в языке.
В мире Linq ей бы соответстовал IQueryable<Tuple<T1, ..., TN>>, если бы у нас были туплы.
Вот тогда можно было бы четко развести бизнес-логику на независимые кирпичи.
Одни функции бы занимались подготовкой реляций, другие — их использованием. Именно это и есть настоящая реляционная алгебра с блэкджеком и шлюхами.
А умение захардкодить конкретное выражение — малоинтересно. Интересны функции высшего порядка.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали: VD>В принципе можно было бы попытаться эмулировать record через tuple, но это довольно сложно. Ведь для этого пришлось бы везде протаскивать расширенную информацию о типах. Придется вводить в компилятор дополнительный тип и кодировать его черт знает каким образом в сборках. В общем, геморрой. И это при том, что tuple (кортежи) решают проблему не намного хуже.
Ну вот примерно это сейчас муссируется в C# Insiders Maillist.
Моя точка зрения примерно такова:
1. Есть анонимные типы. В них удобно то, что компоненты — именованные. Это крайне здорово, т.к. позволяет делать меньше ошибок.
2. В них неудобно то, что их нельзя возвращать.
3. Причем понятно, почему нельзя — они же строго локальны.
4. И даже если бы они были нелокальны, ценности бы это не добавило. Ведь {string Name, int Age} был бы несовместим со {string name, int age}.
5. А интуитивно понятно, что такая совместимость была бы крайне полезна
6. И она как раз есть у туплов — благодаря безымянности полей
7. каждый тупл полностью определяется типами своих аргументов.
8. Поэтому самый руль был бы совместить достоинства и убрать недостатки
9. К примеру, сделать анонимные типы взаимозаменяемыми с туплами
10. Точнее, туплы бы могли быть "официальным лицом" анонимных типов
11. То есть вернуть из метода анонимный тип или его производные было бы по-прежнему нельзя
12. Зато можно было бы вернуть совместимый тупл
13. А имена полей были бы всего лишь локальными алиасами для .Value1, .Value2, etc.
14. Но это плохо для reflection-based сценариев, где имена компонентов важны
15. Поэтому мой мозг пасует перед сложностью задачи.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
G>Есть большая проблема в примерах архитектуреных решений. Маленькие примеры непоказательны, а в больших трудно разобраться, да и многие преимущества и недостатки неочевидны.
А розового слоника в вакууме трогать нельзя, а то забанят. без примеров подобные топики сваливаются после третьего сообщения в маразм.
Я думаю идеальным было бы маааленькое приложение как пример.
С разбором, можно так, можно так. Тут такие плюсы минусы. тут такие...
Здравствуйте, VladD2, Вы писали:
L>>Это зависит от того, что у вас за клиент. В случае веба click по договору приведет к открытию страницы договора, а на новой странице эта инфорация уже не будет доступна и запрашивать все рано придется.
VD>Ага. Но зачем мне получать объект по id? Я лучше получу всю нужную информацию отображаемую на странице.
А как предполагается вытаскивать эту нформацию? Например, в случае того же web-а. Если исползуем вывод типов для запросов типа from c in customer select new { c.id, c.name }, то сразу теряем возможность использовать подобный запрос в более чем одном методе. Если же для каждого такого запроса создаем свой класс-обертку, содержащий id и name, то скоре колиество этих классов разрастется до неимоверных размеров. Как предполагается с этим бороться?
VD>При этом я не хочу вынимать лишнюю информацию. Запрос же объекта по идентификатору — это неэффективное вынимание данных — запрос данных наобум.
А в чем серьезный недстаток вынимания всего объекта? Насколько я понимаю, сервер все равно читает с диска постранично, т.е. все данные, относящиеся к записи все равно будут подняты в память.
VD>>>И select тут будет намного более удобнее. Зачем нам объект? Нам нужно содержимое договора (например).
L>>Если схема данных один-в-один соответствует entity, то будет гораздо удобнее. L>>Если же DAL занимается каким-нибудь преобразованием из резалтсета в entity, то будет уже не так удобно.
VD>Если нужны преобразования, то не трудно написать функцию. Но зато в 99% случаев ты просто напишешь запрос который вынет те данные которые реально нужны.
В случае функции бизнес-код будет содержать информацию о том, как данные хранятся, а такому коду, имхо, не место в бизнесе.
Здравствуйте, Tom, Вы писали:
Tom>Я думаю идеальным было бы маааленькое приложение как пример. Tom>С разбором, можно так, можно так. Тут такие плюсы минусы. тут такие...
Согласен на 1000%. Маленькое приложение как пример было бы супер.
Если нам не помогут, то мы тоже никого не пощадим.
