:: Курилка
Re: Светлая и темная сторона транзакций
Crispy

Сообщений: 18571
Дата регистрации: 16.05.2005
Все жду, когда тут Дарт Вейдер появится и начнет биться то ли с Йодой, то ли с Ван Обием.
Но пока что как-то даже и непонятно, кто тут джедаи, а кто ситхи.


------------------
В действительности все иначе, чем на самом деле.
                                      (Антуан де Сент-Экзюпери)
Ratings: 0 negative/0 positive
Re: Светлая и темная сторона транзакций
_vit

Сообщений: 5173
Дата регистрации: 29.07.2002
Очередная попытка найти философский камень, некое решение которое исправит все одним махом.
Не существует общего правильного решения.
Кроме того все крупные проекты обречены быть "кривыми" так что это судьба сопровождающих в последствии проект программистов лепить костыли и подпорки.
Ratings: 0 negative/0 positive
Re: Светлая и темная сторона транзакций
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
PaulWist
Гулин Федор
... я бы тоже не размазывал логику по БД и App а сувал бы почти все в App
И PK, FK, default, unuque constraint, permission object/users/database итд тоже через App поддерживал бы.

Ну кое что, конечно, БД делает сильно лучше - даже если взять нереляционные

Но default-ы и тем более разграничение прав - увольте.
Вынимать всё взад из БД лишь чтобы получить на клиенте сгенерённую DateTime.Now или Guid.NewGuid() - это либо глупость, либо экстремизм.

А по аутентификации и авторизации - что, твоя СУБД умеет в OpenID? Авторизоваться через фейсбук/гугл/вконтакте или ещё куче подобных сервисов, которые в кои-то веки более-менее стандартно позволяют своих пользователей авторизовать на внешних ресурсах (не заставляя пользователя держать 100500 "аккаунтов" на каждый мелкий сайтик).
Ну и да, менеджмент юзеров в домене (да хоть бы и на самом сервере, если речь не про доменную аутентификацию/авторизацию) для раздачи им прав на всякие разнообразные сервисы да корпоративные приложеньица/модули/функции - на месте админов я бы послал в дальнее пешее путешествие архитектора такое предлагающего
Не предназначен для этого домен, ну ваще не удобен он для таких целей.
P.S. Я уж не говорю про радости установления 100500 соединений - персонально под каждого юзера, вместо простого и мега-эффективного пула, где авторизация и аутентификация (уникальные для каждого пользователя) на уровне соединения не нужны вообще, а всю толпу юзеров может обслужить в 10-20-50 раз меньшее число соединений.


------------------
WBR, Igor
Ratings: 0 negative/1 positive
Re: Светлая и темная сторона транзакций
leonid

Сообщений: 3202
Откуда: Рига
Дата регистрации: 03.02.2006
PaulWist
И PK, FK, default, unuque constraint, permission object/users/database итд тоже через App поддерживал бы.

Может быть Вы не в курсе, но многие именно так и делают. Вы слышали что-нибудь например про Hibernate
hibernate.org
Ratings: 0 negative/0 positive
Re: Светлая и темная сторона транзакций
PaulWist

Сообщений: 14601
Дата регистрации: 01.04.2004
leonid
PaulWist
И PK, FK, default, unuque constraint, permission object/users/database итд тоже через App поддерживал бы.

Может быть Вы не в курсе, но многие именно так и делают. Вы слышали что-нибудь например про Hibernate
hibernate.org

В курсе, спасибо.

На sql.ru с завидной постоянностью приводится автоматический ORM-код для рефакторинга и оптимизации.


------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)




Исправлено 1 раз(а). Последнее : PaulWist, 02.06.20 08:37
Ratings: 0 negative/0 positive
Re: Светлая и темная сторона транзакций
PaulWist

Сообщений: 14601
Дата регистрации: 01.04.2004
Igor Korolyov

Но default-ы и тем более разграничение прав - увольте.
Вынимать всё взад из БД лишь чтобы получить на клиенте сгенерённую DateTime.Now или Guid.NewGuid() - это либо глупость, либо экстремизм.

Хех, зачем? Достаточно закончить транзакцию в БД и вынуть необходимое на клиента.

Igor Korolyov

А по аутентификации и авторизации - что, твоя СУБД умеет в OpenID? Авторизоваться через фейсбук/гугл/вконтакте или ещё куче подобных сервисов, которые в кои-то веки более-менее стандартно позволяют своих пользователей авторизовать на внешних ресурсах (не заставляя пользователя держать 100500 "аккаунтов" на каждый мелкий сайтик).
Ну и да, менеджмент юзеров в домене (да хоть бы и на самом сервере, если речь не про доменную аутентификацию/авторизацию) для раздачи им прав на всякие разнообразные сервисы да корпоративные приложеньица/модули/функции - на месте админов я бы послал в дальнее пешее путешествие архитектора такое предлагающего
Не предназначен для этого домен, ну ваще не удобен он для таких целей.

Не удобен - ДА, кто спорит.

Igor Korolyov
P.S. Я уж не говорю про радости установления 100500 соединений - персонально под каждого юзера, вместо простого и мега-эффективного пула, где авторизация и аутентификация (уникальные для каждого пользователя) на уровне соединения не нужны вообще, а всю толпу юзеров может обслужить в 10-20-50 раз меньшее число соединений.

Да-да, плавали знаем, все ломятся в БД с логином sa/root, а "права" получают enabled/disable/visible у "кнопочек".

PS собственно мы начали по второму кругу, можно закончить тред


------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)




Исправлено 1 раз(а). Последнее : PaulWist, 02.06.20 13:20
Ratings: 0 negative/0 positive
Re: Светлая и темная сторона транзакций
leonid

Сообщений: 3202
Откуда: Рига
Дата регистрации: 03.02.2006
PaulWist
В курсе, спасибо.

И при этом продолжаете считать, что все, кто этим пользуются, используют "косоватую" архитектуру? А та, которой пользуетесь Вы, единственно правильная?

Ratings: 0 negative/0 positive
Re: Светлая и темная сторона транзакций
PaulWist

Сообщений: 14601
Дата регистрации: 01.04.2004
leonid
PaulWist
В курсе, спасибо.

И при этом продолжаете считать, что все, кто этим пользуются, используют "косоватую" архитектуру? А та, которой пользуетесь Вы, единственно правильная?


Строго говоря - "единственно правильная" архитектура это та которая для СУБД является by design.



------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)
Ratings: 0 negative/0 positive
Re: Светлая и темная сторона транзакций
Гулин Федор

Сообщений: 4633
Откуда: Минск
Дата регистрации: 24.10.2002
PaulWist
Гулин Федор
... я бы тоже не размазывал логику по БД и App а сувал бы почти все в App

И PK, FK, default, unuque constraint, permission object/users/database итд тоже через App поддерживал бы.

PK точно НЕТ
остальное обсуждаемо
я больше по OLAP системам спец - там FK вообще зло и не юзатся почти никогда ибо замедляют ETL
для OLTP конечно вариант и наверно в целом положительный

Unique Constaint да наверно ползеная вещь если заранее известно - главное не попасть скажем в номер+серия паспорта UK
а потом придут иносранцы - и чего туда вводить длня них N/A - и все UK полетел.

permission object/users/database - это я вообще примерно понимаю
если допустим речь что группы юзеров работают под групповыми SQL юзерами
(типа Admins под админами , чтение под R/O юзером ) - для большей безопасноит - ну ок
тут можно по разному подходить

PS опять же со времен 2008 я не писал OLTP (под VFP я сделал бы как мне удобней)
поэтому я тут больше смотрю на мысли людей
кстати где то в 2008 я заводил тему про ООП и ява когда сидел техн. аналитике на 3 звенном проект ява + db2 к-й портировало
большое число ( > 60 на пике точно ) девелоперов с немецкого проекта на смоллтоке
ох там и код был - просто сказка - понять что-то БЕЗ отладчика там было в принципе НЕ возможно.
Ratings: 0 negative/0 positive
Re: Светлая и темная сторона транзакций
PaulWist

Сообщений: 14601
Дата регистрации: 01.04.2004
Гулин Федор

PK точно НЕТ
остальное обсуждаемо
я больше по OLAP системам спец - там FK вообще зло и не юзатся почти никогда ибо замедляют ETL
для OLTP конечно вариант и наверно в целом положительный


Ммм, а кластерные индексы используются?


------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)
Ratings: 0 negative/0 positive
Re: Светлая и темная сторона транзакций
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
PaulWist
Igor Korolyov
Вынимать всё взад из БД лишь чтобы получить на клиенте сгенерённую DateTime.Now или Guid.NewGuid() - это либо глупость, либо экстремизм.
Хех, зачем? Достаточно закончить транзакцию в БД и вынуть необходимое на клиента.
О чём и речь - лишние операции. Если б я на каждый insert получал не просто статус да/нет а обратно посланные данные, то это было бы совершенно очевидной избыточной нагрузкой.
Если тебя смутило слово "всё" - так не суть важно 50 полей, или всего 5 - хотя с точки зрения архитектуры системы "всё силами СУБД" клиент настолько прост/туп, что понятия не имеет что там сервер понаизменяет в отосланных на него данных, а значит таки ВСЁ надо возвращать - он (клиент) в принципе "состояние" не может в таком случае отслеживать.
Опять же в этом случае исчезает смысл среднего слоя - если ВСЁ делает субд - от реализации бизнес логики до авторизации, то на кой чёрт нужен "слой бизнес-логики"
PaulWist
Да-да, плавали знаем, все ломятся в БД с логином sa/root, а "права" получают enabled/disable/visible у "кнопочек".
Ты знаешь, очень успешно (и весьма безопасно) используют сейчас СУБД где вообще авторизация сведена к минимуму, или является необязательной - и да, весь "функционал" разграничивается на уровне сервисов - а сервис это совсем не СУБД. Более того, далеко не всякий сервис нуждается в постоянном хранении какой-либо информации, но многие сервисы нуждаются в аутентификации и авторизации.
Если кто-то когда-то не сумел в создание нормальной системы аутентификации/авторизации, то это абсолютно не значит что это невозможно и что надо тянуть всю security часть в СУБД


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Светлая и темная сторона транзакций
Гулин Федор

Сообщений: 4633
Откуда: Минск
Дата регистрации: 24.10.2002
PaulWist
Гулин Федор

PK точно НЕТ
остальное обсуждаемо
я больше по OLAP системам спец - там FK вообще зло и не юзатся почти никогда ибо замедляют ETL
для OLTP конечно вариант и наверно в целом положительный


Ммм, а кластерные индексы используются?

не понял вопроса - точнее контекста - к чему
в OLTP системе на прошлой работе кластенрые индексы в sql server 2012 почти везде
в OLAP по разному
если ТФ с кучей ключей ид-к я предпочитаю НЕ использовать
но если сделать идентити - то почему бы и нет

у меня была 1 раз замануха с кластерным индексом в 2016 когда надо было удалить большой кусок таблицы (50 млн - это где то 0.5%)
не из конца таблицы
пришлось переделать на некластерный - но это частный случай - возможно я не учел там чего-то - не было времени разбираться
вообщем именно из за возможности удаления (перезаливки ) больших кусков я в OLAP не люблю использовать кластерные индексы
Ratings: 0 negative/0 positive
Re: Светлая и темная сторона транзакций
PaulWist

Сообщений: 14601
Дата регистрации: 01.04.2004
Гулин Федор
не понял вопроса - точнее контекста - к чему
в OLTP системе на прошлой работе кластенрые индексы в sql server 2012 почти везде
в OLAP по разному
если ТФ с кучей ключей ид-к я предпочитаю НЕ использовать
но если сделать идентити - то почему бы и нет

у меня была 1 раз замануха с кластерным индексом в 2016 когда надо было удалить большой кусок таблицы (50 млн - это где то 0.5%)
не из конца таблицы
пришлось переделать на некластерный - но это частный случай - возможно я не учел там чего-то - не было времени разбираться
вообщем именно из за возможности удаления (перезаливки ) больших кусков я в OLAP не люблю использовать кластерные индексы

Ну, кластерный индекс нужен что бы избежать RID на куче.


------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)
Ratings: 0 negative/0 positive
Re: Светлая и темная сторона транзакций
PaulWist

Сообщений: 14601
Дата регистрации: 01.04.2004
Igor Korolyov
О чём и речь - лишние операции. Если б я на каждый insert получал не просто статус да/нет а обратно посланные данные, то это было бы совершенно очевидной избыточной нагрузкой.

Зависит от задачи. Если клиенту не нужны промежуточные/конечные вычисления бизнес логики, то достаточно статуса да/нет, а если нужны, то обратно полученные данные вполне необходимы не вижу ни какого экстремизма

Igor Korolyov

Опять же в этом случае исчезает смысл среднего слоя - если ВСЁ делает субд - от реализации бизнес логики до авторизации, то на кой чёрт нужен "слой бизнес-логики"

Ну собственно, мы об этом "бодаемся" чуть ли не пятилетку

Масштабируемость, в принципе вещь необходимая.

Igor Korolyov

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

1. В парадигме микросервисов МЫ ВСЕ писали ещё на Fox2.0 (а некоторое и раньше), назывались тогда эти микросервисы "АРМ кассира", "АРМ бухгалтера", "АРМ лаборатория" итд
А ещё эти "АРМ микросервисы" были связаны с разными БД, которые (БД) не поддерживали консистентность данных, чистяк современный подход

2. Я слабо представляю как/через что микросервис получает доступ к БД, особенно если он не использует её security (можно конечно в текстовый файл писать, но не об этом речь)


------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)




Исправлено 1 раз(а). Последнее : PaulWist, 05.06.20 21:44
Ratings: 0 negative/0 positive
Re: Светлая и темная сторона транзакций
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
PaulWist
Igor Korolyov
Опять же в этом случае исчезает смысл среднего слоя - если ВСЁ делает субд - от реализации бизнес логики до авторизации, то на кой чёрт нужен "слой бизнес-логики"
Ну собственно, мы об этом "бодаемся" чуть ли не пятилетку
Масштабируемость, в принципе вещь необходимая.
РСУБД штука крайне плохо масштабируемая что горизонтально, что вертикально... Потому то и предпочитают использовать более приспособленные для масштабирования вещи. А в них зачастую основополагающие принципы РСУБД напрочь отвергаются, заменяясь на совсем другие. Другое дело что это не нужно для многих применений.
PaulWist
2. Я слабо представляю как/через что микросервис получает доступ к БД, особенно если он не использует её security (можно конечно в текстовый файл писать, но не об этом речь)
Микросервис, если ему нужно хранилище, получает к нему доступ совершеннго обычными средствами - через клиентские библиотеки - дотнет провайдеры, jdbc если речь про реляционные БД, или свои библиотеки для нереляционных. И да, как правило никаких функций безопасности СУБД тут не требуется от слова совсем. Да и расчётные не так уж чтобы и часто нужны бывают - узкое место, да, могут прикрыть, а так чтобы вот прям всё реализовывать на tsql/plsql и им подобных - ну я такого не встречал. Гораздо эффекивнее, проще и надёжнее писать код на обычных языках, а не на встроенных языках той или иной СУБД. Равно и изменять его.


------------------
WBR, Igor
Ratings: 0 negative/0 positive


Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 25 (Гостей: 25)

© 2000-2024 Fox Club 
Яндекс.Метрика