Re: Светлая и темная сторона транзакций | |
---|---|
Crispy Сообщений: 18571 Дата регистрации: 16.05.2005 |
Все жду, когда тут Дарт Вейдер появится и начнет биться то ли с Йодой, то ли с Ван Обием.
Но пока что как-то даже и непонятно, кто тут джедаи, а кто ситхи. ------------------ В действительности все иначе, чем на самом деле. (Антуан де Сент-Экзюпери) |
Re: Светлая и темная сторона транзакций | |
---|---|
_vit Сообщений: 5173 Дата регистрации: 29.07.2002 |
Очередная попытка найти философский камень, некое решение которое исправит все одним махом.
Не существует общего правильного решения. Кроме того все крупные проекты обречены быть "кривыми" так что это судьба сопровождающих в последствии проект программистов лепить костыли и подпорки. |
Re: Светлая и темная сторона транзакций | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Ну кое что, конечно, БД делает сильно лучше - даже если взять нереляционные Но default-ы и тем более разграничение прав - увольте. Вынимать всё взад из БД лишь чтобы получить на клиенте сгенерённую DateTime.Now или Guid.NewGuid() - это либо глупость, либо экстремизм. А по аутентификации и авторизации - что, твоя СУБД умеет в OpenID? Авторизоваться через фейсбук/гугл/вконтакте или ещё куче подобных сервисов, которые в кои-то веки более-менее стандартно позволяют своих пользователей авторизовать на внешних ресурсах (не заставляя пользователя держать 100500 "аккаунтов" на каждый мелкий сайтик). Ну и да, менеджмент юзеров в домене (да хоть бы и на самом сервере, если речь не про доменную аутентификацию/авторизацию) для раздачи им прав на всякие разнообразные сервисы да корпоративные приложеньица/модули/функции - на месте админов я бы послал в дальнее пешее путешествие архитектора такое предлагающего Не предназначен для этого домен, ну ваще не удобен он для таких целей. P.S. Я уж не говорю про радости установления 100500 соединений - персонально под каждого юзера, вместо простого и мега-эффективного пула, где авторизация и аутентификация (уникальные для каждого пользователя) на уровне соединения не нужны вообще, а всю толпу юзеров может обслужить в 10-20-50 раз меньшее число соединений. ------------------ WBR, Igor |
Re: Светлая и темная сторона транзакций | |
---|---|
leonid Сообщений: 3202 Откуда: Рига Дата регистрации: 03.02.2006 |
Может быть Вы не в курсе, но многие именно так и делают. Вы слышали что-нибудь например про Hibernate hibernate.org |
Re: Светлая и темная сторона транзакций | |
---|---|
PaulWist Сообщений: 14601 Дата регистрации: 01.04.2004 |
В курсе, спасибо. На sql.ru с завидной постоянностью приводится автоматический ORM-код для рефакторинга и оптимизации. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) Исправлено 1 раз(а). Последнее : PaulWist, 02.06.20 08:37 |
Re: Светлая и темная сторона транзакций | |
---|---|
PaulWist Сообщений: 14601 Дата регистрации: 01.04.2004 |
Хех, зачем? Достаточно закончить транзакцию в БД и вынуть необходимое на клиента.
Не удобен - ДА, кто спорит.
Да-да, плавали знаем, все ломятся в БД с логином sa/root, а "права" получают enabled/disable/visible у "кнопочек". PS собственно мы начали по второму кругу, можно закончить тред ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) Исправлено 1 раз(а). Последнее : PaulWist, 02.06.20 13:20 |
Re: Светлая и темная сторона транзакций | |
---|---|
leonid Сообщений: 3202 Откуда: Рига Дата регистрации: 03.02.2006 |
|
Re: Светлая и темная сторона транзакций | |
---|---|
PaulWist Сообщений: 14601 Дата регистрации: 01.04.2004 |
Строго говоря - "единственно правильная" архитектура это та которая для СУБД является by design. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) |
Re: Светлая и темная сторона транзакций | |
---|---|
Гулин Федор Автор Сообщений: 4633 Откуда: Минск Дата регистрации: 24.10.2002 |
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 на пике точно ) девелоперов с немецкого проекта на смоллтоке ох там и код был - просто сказка - понять что-то БЕЗ отладчика там было в принципе НЕ возможно. |
Re: Светлая и темная сторона транзакций | |
---|---|
PaulWist Сообщений: 14601 Дата регистрации: 01.04.2004 |
Ммм, а кластерные индексы используются? ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) |
Re: Светлая и темная сторона транзакций | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
О чём и речь - лишние операции. Если б я на каждый insert получал не просто статус да/нет а обратно посланные данные, то это было бы совершенно очевидной избыточной нагрузкой. Если тебя смутило слово "всё" - так не суть важно 50 полей, или всего 5 - хотя с точки зрения архитектуры системы "всё силами СУБД" клиент настолько прост/туп, что понятия не имеет что там сервер понаизменяет в отосланных на него данных, а значит таки ВСЁ надо возвращать - он (клиент) в принципе "состояние" не может в таком случае отслеживать. Опять же в этом случае исчезает смысл среднего слоя - если ВСЁ делает субд - от реализации бизнес логики до авторизации, то на кой чёрт нужен "слой бизнес-логики" Ты знаешь, очень успешно (и весьма безопасно) используют сейчас СУБД где вообще авторизация сведена к минимуму, или является необязательной - и да, весь "функционал" разграничивается на уровне сервисов - а сервис это совсем не СУБД. Более того, далеко не всякий сервис нуждается в постоянном хранении какой-либо информации, но многие сервисы нуждаются в аутентификации и авторизации. Если кто-то когда-то не сумел в создание нормальной системы аутентификации/авторизации, то это абсолютно не значит что это невозможно и что надо тянуть всю security часть в СУБД ------------------ WBR, Igor |
Re: Светлая и темная сторона транзакций | |
---|---|
Гулин Федор Автор Сообщений: 4633 Откуда: Минск Дата регистрации: 24.10.2002 |
не понял вопроса - точнее контекста - к чему в OLTP системе на прошлой работе кластенрые индексы в sql server 2012 почти везде в OLAP по разному если ТФ с кучей ключей ид-к я предпочитаю НЕ использовать но если сделать идентити - то почему бы и нет у меня была 1 раз замануха с кластерным индексом в 2016 когда надо было удалить большой кусок таблицы (50 млн - это где то 0.5%) не из конца таблицы пришлось переделать на некластерный - но это частный случай - возможно я не учел там чего-то - не было времени разбираться вообщем именно из за возможности удаления (перезаливки ) больших кусков я в OLAP не люблю использовать кластерные индексы |
Re: Светлая и темная сторона транзакций | |
---|---|
PaulWist Сообщений: 14601 Дата регистрации: 01.04.2004 |
Ну, кластерный индекс нужен что бы избежать RID на куче. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) |
Re: Светлая и темная сторона транзакций | |
---|---|
PaulWist Сообщений: 14601 Дата регистрации: 01.04.2004 |
Зависит от задачи. Если клиенту не нужны промежуточные/конечные вычисления бизнес логики, то достаточно статуса да/нет, а если нужны, то обратно полученные данные вполне необходимы не вижу ни какого экстремизма
Ну собственно, мы об этом "бодаемся" чуть ли не пятилетку Масштабируемость, в принципе вещь необходимая.
1. В парадигме микросервисов МЫ ВСЕ писали ещё на Fox2.0 (а некоторое и раньше), назывались тогда эти микросервисы "АРМ кассира", "АРМ бухгалтера", "АРМ лаборатория" итд А ещё эти "АРМ микросервисы" были связаны с разными БД, которые (БД) не поддерживали консистентность данных, чистяк современный подход 2. Я слабо представляю как/через что микросервис получает доступ к БД, особенно если он не использует её security (можно конечно в текстовый файл писать, но не об этом речь) ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) Исправлено 1 раз(а). Последнее : PaulWist, 05.06.20 21:44 |
Re: Светлая и темная сторона транзакций | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
РСУБД штука крайне плохо масштабируемая что горизонтально, что вертикально... Потому то и предпочитают использовать более приспособленные для масштабирования вещи. А в них зачастую основополагающие принципы РСУБД напрочь отвергаются, заменяясь на совсем другие. Другое дело что это не нужно для многих применений.
------------------ WBR, Igor |
© 2000-2024 Fox Club  |