killer8080
6.01.2017 - 00:01
Цитата (Guest @ 6.01.2017 - 00:00) |
Никогда не нужно, а вот иногда имеет смысл. Если будем шардить таблицы по серверам |
ключевое слово "если"
kaww, ну и автоинкремент это полезная вещь, во всех правилах бывают исключения. Правда я на работе не использую даже эту функцию СУБД (инкрементальные идентификаторы), потому что апликуха так написана, она генерит guid.
Цитата (kaww @ 5.01.2017 - 23:41) |
В системах, когда одну БД используют несколько независимых компонентов, реализация логики хранилища именно в хранилище (внезапно) выглядит более чем логичн |
прям и вспоминается это
https://www.youtube.com/watch?v=BFsIAgwhs9s после таких слов
почему эту логику(из разных приложений) не запихнуть в апликуху над СУБД? Ведь большинство приложений сейчас так и строятся.
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
Цитата (sergeiss @ 5.01.2017 - 23:58) |
ГДЕ реализовывать бизнес-логику? Одновременно на сервере и в мобильном приложении? |
Нет. Нужно нужно просто RESTful API сделать или что угодно, главное чтобы это что-то отдавало данные. Мобильное приложение это просто один из потребителей данных.
Блин, ты на ангуляре там что-то пишешь, должен знать такие вещи.
Цитата (Guest @ 6.01.2017 - 00:09) |
Нет. Нужно нужно просто RESTful API сделать или что угодно, главное чтобы это что-то отдавало данные |
вот о чём то подобном я и хотел сказать.
А вообще Oyeme как архитектор приложений нам бы тут расписал правильную точку зрения, жаль что он еще не отписался в этой теме.
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
chee, кто определяет ту грань полезного и бесполезного. И почему view - это вредно, а auto increment вдруг полезно.
Цитата (chee @ 6.01.2017 - 00:04) |
почему эту логику не запихнуть в апликуху над БД? |
Таких аппликух может быть больше чем одна. и в каждую надо запихнуть, и не забыть везде поддерживать потом.
Цитата (chee @ 6.01.2017 - 00:04) |
Правда я на работе не использую даже эту функцию СУБД (инкрементальные идентификаторы), потому что апликуха так написана, она генерит guid. |
Красава. Мы тоже не используем. Если сравнить плюсы и минусы, то минусов будет больше.
sergeiss
6.01.2017 - 00:20
Вот уж не думал, что из триггера БД можно сделать "холивар"
А оказывается можно...
Я на эту тему высказался, больше спорить не хочу. Противники триггеров и других полезностей БД могут их не использовать, это их личное дело. Я же буду делать так, как считаю более полезным и нужным.
_____________
*
Хэлп по PHP*
Описалово по JavaScript *
Хэлп и СУБД для PostgreSQL*
Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги. *
"накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
Цитата (kaww @ 6.01.2017 - 00:14) |
Таких аппликух может быть больше чем одна. и в каждую надо запихнуть, и не забыть везде поддерживать потом. |
А нахрена нам вообще зарплату-то платят, естественно все это нужно поддерживать, но поддерживать это будет не так сложно как лапшичку на процедурах в СУБД.
Цитата (kaww @ 6.01.2017 - 00:14) |
кто определяет ту грань полезного и бесполезного. И почему view - это вредно, а auto increment вдруг полезно. |
здравый смысл и система выбора (с обязательной ответственность за свой выбор). Мы должны быть прагматичными и предугадывать последствия, я исхожу из этих суждений в данном вопросе. Ну и конечно, а разве view не инкапсулирует определенный запрос, какая тут логика приложения? вроде view это агрегация данных.
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
sergeiss, так ты не спорь. Просто попробуй аргументированно донести до нас, почему мы должны их использовать. Одно дело когда данные практически напрямую валятся из БД во фронтенд и бекенда как такового нет вообще. Другое дело когда у тебя есть полноценный бекенд и вместо того, чтобы инкапсулировать всю логику там ты её растаскиваешь хз куда.
sergeiss
6.01.2017 - 00:33
Цитата (Guest @ 6.01.2017 - 00:26) |
sergeiss, так ты не спорь. Просто попробуй аргументированно донести до нас, почему мы должны их использовать. |
Я уже приводил свои аргументы. Честно говоря, не хочу повторяться.
Цитата (chee @ 6.01.2017 - 00:24) |
но поддерживать это будет не так сложно как лапшичку на процедурах в СУБД. |
Поддерживать лапшичку в нескольких местах будет удобнее, чем в одном?
_____________
*
Хэлп по PHP*
Описалово по JavaScript *
Хэлп и СУБД для PostgreSQL*
Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги. *
"накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
Цитата (sergeiss @ 6.01.2017 - 00:33) |
Поддерживать лапшичку в нескольких местах будет удобнее, чем в одном? wink.gif |
тут вопрос в качестве лапшички, я видел на чем пишут процедурки в СУБД, там явно просроченные макаронные изделия
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
sergeiss, лучше объясни как так получается, что у тебя несколько приложений делают одну и ту же логику, что вдруг это общее понадобилось вынести в триггер.
Пишем первое приложение. Его суть:
Цитата |
чтоб при добавлении юзером денег, у его реферера сумма увеличивалась на 10 процентов от внесенных средств. |
Пишем второе приложение. Его суть:
Цитата |
чтоб при добавлении юзером денег, у его реферера сумма увеличивалась на 10 процентов от внесенных средств. |
Guest, ну тут ты его не совсем понял, речь шла о двух приложениях у которых, допустим, 50% уникальной функциональности, а 50% общей. Я думаю он это имел ввиду.
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
sergeiss
6.01.2017 - 00:55
Цитата (Guest @ 6.01.2017 - 00:42) |
sergeiss, лучше объясни как так получается, что... |
А ты лучше объясни, как так получается, что пишем 2 приложения, работающие с одной БД и дублируем функционал на уровне приложений? Это реально двойная работа! Я бы даже сказал, что это вообще нереально двойная работа
За которую надо уменьшать зряплату тому, кто так организует рабочий процесс. Или вообще нахрен увольнять и брать другого, более грамотного. Тут же не только разработка, но и тестирование дублируются. Да еще и сравнивать надо алгоритмы в разных приложениях. А если потом изменения вносятся? Надо ж не забыть изменить в нескольких местах. Да еще желательно сделать это одновременно!!! Иначе можем получить нехилые такие грабли.
Я уже говорил, что сейчас приходится много работать с индусами. Вот у них дублирование разработки "в порядке вещей". Не хочу быть похожим на индусов... Хотя и приходится говнокодить иногда, общаясь с ними.
Хочу, по возможности, писать правильный код.
_____________
*
Хэлп по PHP*
Описалово по JavaScript *
Хэлп и СУБД для PostgreSQL*
Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги. *
"накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
вот у вас спор то тут. тут как с дампами. также и программисты. те кто не использует триггеры и те кто уже использует. видимо, еще не дорос. не в обиду сказано.
триггеры это прежде всего целостность данных. и никто в жизни не сможет доказать что на уровне приложения можно поддержать целостность данных лучше, чем на уровне встроенных средств бд.
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.