Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Обновление PostgreSQL с устранением уязвимостей. Выпуск балансировщика соединений Odyssey 1.2"	+/–
Сообщение от opennews (ok), 14-Ноя-21, 09:56
Сформированы корректирующие обновления для всех поддерживаемых веток PostgreSQL:  14.1, 13.5, 12.9, 11.14, 10.19 и 9.6.24. Выпуск 9.6.24 станет последним обновлением для ветки 9.6, поддержка которой прекращена. Обновления для ветки 10 будут формироваться до ноября 2022 года, 11 - до ноября 2023 года, 12  - до ноября 2024 года, 13 - до ноября 2025 года, 14 - до ноября 2026 года... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56151
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от BratishkaErik (ok), 14-Ноя-21, 09:56	+1 +/–
Их документация очень годная, приятно читать
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8

2. Сообщение от iZEN (ok), 14-Ноя-21, 11:30	–7 +/–
Чем оно лучше InterBase 2020 в техническом плане?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #7

3. Сообщение от Аноним (3), 14-Ноя-21, 11:35	–13 +/–
Делал летом обновление с 12  на 13... Вернулся на MySQL
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #12

4. Сообщение от Цезий Родонович (?), 14-Ноя-21, 11:50	–6 +/–
Годная документация у оракла особенно эдак версии 8.0.5, ещё не засранной скриншотами, а это так подобие левой руки.
Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от Цезий Родонович (?), 14-Ноя-21, 11:51	+2 +/–
Всем!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

6. Сообщение от ыы (?), 14-Ноя-21, 12:01	+24 +/–
Это надо уметь... Обновить постгрес до мускуля :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #16, #36

7. Сообщение от ыы (?), 14-Ноя-21, 12:02	+/–
Ну во первых  InterBase не поддерживается 1С... Во вторых... Впрочем и первого хватит :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #13

8. Сообщение от Прохожий (??), 14-Ноя-21, 12:06	+2 +/–
Вообще-то нет. Ни слова об архитектуре. Многие вещи, довольно критичные для администрирования, приходится по Интернету собирать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #9

9. Сообщение от ыы (?), 14-Ноя-21, 12:11	–1 +/–
Надо полагать товарищи в интернете которые рассказали вам об искомом- тем не менее как-то смогли получить данные об архитектуре... Обычно они их получают как раз из документации...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #11, #51, #52, #54

10. Сообщение от Аноним (10), 14-Ноя-21, 12:35	+/–
Так из-за чего уязвимость была? Признавайтесь, опять в указателях запутались?
Ответить | Правка | Наверх | Cообщить модератору

11. Сообщение от А где же каменты (?), 14-Ноя-21, 12:48	+/–
Из исходного кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

12. Сообщение от Аноним (12), 14-Ноя-21, 13:30	+/–
с чем были проблемы? просто интересуюсь для общего развития
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #15, #17

13. Сообщение от ip1982 (ok), 14-Ноя-21, 15:37	+2 +/–
Держи: - - , , ,
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

14. Сообщение от лютый жабби__ (?), 14-Ноя-21, 17:10	–2 +/–
Тут дамп PG дали. pg_restore -C даже таблицу создать не может... создаешь таблицу, кодировка цп1251 (гы-гы в 2021м году-то)... в таблице половина полей обычные, одно JSONB. вычитать поле bigint[] jooq обосрлся... в голом jdbc это поле считать надо несколько команд.... работать с JSON вообще жесть - в psql каша, SQL запросы по работе с jsonb наркоманские....... ну и самый трэш: монга с 3.2 до 5.0 обновляется апдейтом бинарников, сначала слэйвы, потом мастер. без сучка и задоринки....  а слонятину надо стопать и дамп рестор дрчить... ещё в слоне постоянно csv. я вот не понимаю как можно в здравом уме использовать pg в проде...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19, #23, #24, #53

15. Сообщение от An (??), 14-Ноя-21, 18:28	+3 +/–
Видимо с руками... Обновлялся весной с 11 на 13 - все ок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

16. Сообщение от Онаним (?), 14-Ноя-21, 20:17	–6 +/–
Надо сказать, обновить постгрес до мускля - это очень правильное решение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #21

17. Сообщение от Аноним (17), 14-Ноя-21, 20:24	–1 +/–
Проблем ни с чем не было. Всё обновилось. Но сама методика обновления убила. Делал всё по официальной документации. Так вот - это всё какая то дичь: нужно иметь две установленных версии PostgreSQL, что бы смигрировать базы с одной версии на более свежую. Это в самом простом случае. Ведь при запуске нового сервера, автоматическая миграция по какой либо причине может збойнуть и тогда привет данным (если нет бекапов, опустим вопрос о том, что они всегда должны быть перед этой процедурой). А вот в MySQL всего лишь pkg remove mysql56-server; pkg install mysql8.0-server; mysql_upgrade.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #18, #20

18. Сообщение от An (??), 14-Ноя-21, 21:27	+/–
>> нужно иметь две установленных версии PostgreSQL Действительно дичь, поддерживаю. >>Ведь при запуске нового сервера, автоматическая миграция по какой либо причине может збойнуть и тогда привет данным... Только в одном случае - при использовании ключика -k(если память мне не изменяет). Если его не использовать - старый кластер обновление не затронет. >>А вот в MySQL всего лишь pkg remove mysql56-server; pkg install mysql8.0-server; mysql_upgrade. Тоже может сбойнуть и тогда: "привет данным (если нет бекапов"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #28

19. Сообщение от ыы (?), 14-Ноя-21, 21:30	+3 +/–
>даже таблицу создать не может... создаешь таблицу, кодировка цп1251 (гы-гы в 2021м году-то) Виндузятник должен страдать... :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #30

20. Сообщение от ыы (?), 14-Ноя-21, 21:34	+2 +/–
А ради интереса, обновите оракл с 10 на 19 версию :) Ну, чтоб получить полное представление о том что такое хорошо и что такое плохо..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #25, #26, #56, #61

21. Сообщение от ыы (?), 14-Ноя-21, 21:42	+/–
Знаете сказку про пшикмастера?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

22. Сообщение от Анонус (?), 14-Ноя-21, 23:45	+/–
А чем этот яндесовский выблюн лучше pgpool?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33, #46

23. Сообщение от Аноним (23), 15-Ноя-21, 00:26	–1 +/–
> я вот не понимаю Заметно :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

24. Сообщение от RNZ (ok), 15-Ноя-21, 02:48	–1 +/–
> я вот не понимаю как можно в здравом уме использовать pg в проде... Вот так: $ for h in {01,02,03}; do ssh vm$h-prod pgrep -c postgres; done 5130 5122 5198
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #29, #31

25. Сообщение от btrfs (?), 15-Ноя-21, 04:20	–1 +/–
А разме рман уже не комильфо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #67

26. Сообщение от _ (??), 15-Ноя-21, 05:24	+/–
А где ж еЯ (10-ку) - взять то? А так - с 12 на 19 перешли. Брат жив.(C)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

27. Сообщение от Аноним (27), 15-Ноя-21, 05:55	–1 +/–
Мда, релиз был 11 числа, а рач до сих пор даже в тестинг не выкатил. Вот тебе и rolling-release.
Ответить | Правка | Наверх | Cообщить модератору

28. Сообщение от x3who (?), 15-Ноя-21, 08:53	–2 +/–
> Если его не использовать - старый кластер обновление не затронет. не очень себе представляю на проде с терабайтами данных. надо где-то взять избыточный сторадж, потом ждать неделю пока оно перекатит данные, а бизнес пока подождёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #32

29. Сообщение от x3who (?), 15-Ноя-21, 09:03	–1 +/–
а чо не ssh vm{01,02,03}-prod pgrep -c postgres ? Ти что тебе даёт знание этих пидов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #86, #87

30. Сообщение от лютый жабби__ (?), 15-Ноя-21, 09:18	–3 +/–
>Виндузятник должен страдать... вы в своем поделии не разбираетесь, дебиан 10 на том сервере, в /etc/locale.gen было только en_US.UTF-8 UTF-8 что не мешало ни монге, ни любому другому софту вплоть до vim-а прекрасно показывать "русские" уникодные символы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

31. Сообщение от Онаним (?), 15-Ноя-21, 10:10	+1 +/–
> Вот так: > $ for h in {01,02,03}; do ssh vm$h-prod pgrep -c postgres; done > 5130 > 5122 > 5198 И потом kill -9 адресно по пидам, угу. Ну и именование... vm0x-prod - похоже на какой-то колхозный сохошный локалхост.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #34, #85

32. Сообщение от An (??), 15-Ноя-21, 12:30	+4 +/–
В таком случае это делается с ключиком -k, но на реплике, т.к. это самый быстрый и безопасный вариант. Потому, как если это делать на проде - в случае факапа простой будет сильно дольше(и в случае с mysql тут ничего не меняется). Если у вас при таком объеме БД нет реплики - значит ваш бизнес соласен ждать. Если нет и бэкапа - значит данные вам просто не нужны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

33. Сообщение от San (??), 15-Ноя-21, 12:36	+/–
Пока эта яндексовская софтина не заимеет функционал переключения ролей серверов с потоковой репликацией, наверное ничем...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

34. Сообщение от helgi (??), 15-Ноя-21, 13:06	+/–
Приведите пример "правильных" имен. А то у нас в проде вообще зоопарк с именами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #41, #42, #44, #45, #47

35. Сообщение от Аноним (35), 15-Ноя-21, 13:35	+/–
Odyssey  кто-нибудь использует в проде?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37

36. Сообщение от Аноним (36), 15-Ноя-21, 15:12	+/–
Uber так и сделал
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #38

37. Сообщение от funny.falcon (?), 15-Ноя-21, 17:04	+3 +/–
Яндекс
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

38. Сообщение от ыы (?), 15-Ноя-21, 17:29	+/–
ну и где теперь эта uber? Uber в 2019 году получила убыток в $8,5 млрд Uber увеличила чистый убыток в III квартале и т.д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #39, #55

39. Сообщение от Аноним (39), 15-Ноя-21, 19:49	+2 +/–
Дорого им обновление вышло, однако...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

41. Сообщение от Онаним (?), 15-Ноя-21, 21:09	+1 +/–
Silver bullet не существует. Посмотрите роль этих серверов. Если у вас там только postgresql, то началом может быть что-то типа хотя бы pg-01.prod.<project name> Если там наколхожено всё вместе с постгресом, то сначала надо это разобрать на отдельные роли, а потом уже называть соответственно. Просто vm01-prod даже роли сервера не указывает, а это плохо, пойди сразу догадайся, что там pg основная роль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

42. Сообщение от Онаним (?), 15-Ноя-21, 21:11	+/–
Если есть география или какая-то прочая локация - привязывайтесь к геонеймам. Типа pg01.new-york.prod.<project>, или pg01.rack01.dc01.prod.project, или pg01.prod.project.rack01.dc01, или... Короче вариантов тьма, но стоит думать о том, чтобы по названию сервера моментально понимать - что он, зачем он, и где он, это как минимум. Если есть шардинг, всё ещё усложняется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #48

44. Сообщение от Онаним (?), 15-Ноя-21, 21:13	+/–
Иначе будет. "Ой, у нас vm22-prod упал в мониторинге". А где это vm22-prod вообще, что он делает? Я дома, и пока я там включаю десктоп, запускаю VPN, открываю сопроводиловку - я уже примерно представляю, что сервак делает, что легло вместе с ним (и легло ли вообще, если часть кластера/вторичный шард по названию или неприоритетный проект/регион - могу смело не торопиться и зад не рвать, всё либо работает, либо то, что не работает - не критично на некоторое время. Ну или наоборот - надо срочно рвать зад...)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #50

45. Сообщение от Онаним (?), 15-Ноя-21, 21:15	+/–
Если у вас конечно у серваков полное равноправие и все они одинаковые, то можно даже и так оставить - но когда появится второй проект, будет у вас vm123-prod2... и это уже шлак.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

46. Сообщение от Аноним (46), 15-Ноя-21, 21:16	+/–
Видимо, тем, что написан в яндексе. У этих ребят есть своя база данных (возможно и не одна, более-менее взлетел только кликхаус), своя система контроля версий (просирает данные), свой багтрекер (вроде бы, сам я не видел), ну короче всё то, что проще самим написать ради премии и прохождения перформанс-ревью (а документацию к существующему сдвг-олимпиадникам осилить сложно).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #59, #60

47. Сообщение от Онаним (?), 15-Ноя-21, 21:16	+/–
Короче, делайте так, чтобы даже без документации вам было хотя бы очень приблизительно понятно, о какой машине речь, и за что она отвечает. И не только вам, но и желательно новичку допустим пришедшему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

48. Сообщение от Онаним (?), 15-Ноя-21, 21:25	+/–
balancer.web.kb.sw.xen4 http1.web.kb.us.xen1 http2.web.kb.sw.xen4 mysql1.galera.kb.us.xen1 mysql2.galera.kb.sw.xen4 garb.galera.kb.ru.xen2 ocfs2-arb.iscsi.kb.ru.xen2 Тоже не полный сахар, показываю полный примитив, но позволяет понять, о чём речь. kb - внутренняя knowledge base balancer/http/mysql/garb/ocfs2-arb - тип и номер ноды в кластере (балансер, вебня, мускул, арбитратор галеры, арбитрационные LUN для OCFS2) web/galera/iscsi - общая роль (LAMP, mysql galera cluster, iscsi target) xen - пулы виртуализации, они могут быть частями cross-country, поэтому страна вторична us/sw/ru - страны
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #49, #88

49. Сообщение от Онаним (?), 15-Ноя-21, 21:27	+/–
Допустим если мне кивнут на garb/ocfs2-arb или одну из нод, я задницу рвать не буду. А вот если кивнут на balancer - буду, он один по не зависящим от меня причинам :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

50. Сообщение от ыы (?), 15-Ноя-21, 21:59	+/–
Чаще бывает иначе... "Ой, У нас синий расчетный кластер недоступен".... Мучительно вспоминаешь что это такое вообще...и почему они уверены что я должен знать что это такое... А ёпт, это же  vm22-prod... ssh vm22-prod
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #73

51. Сообщение от Антонимистично (?), 15-Ноя-21, 22:14	+1 +/–
Ставишь дебажные символы, дебагер. Почитать придётся. И погнал смотреть как работает. А через месячишко знаешь как админить и есть о чём написать на форумах. Такая она сермяга девляпсов, наследников админов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

52. Сообщение от keydon (ok), 15-Ноя-21, 22:20	+/–
Обычно приходит какой-нибудь чувак на конференцию и начинает с умным видом в очередной раз рассказывать или даже пишет целую очередную статью что дефолтные настройки постгри с расчетом "лишь бы запустилось" а не чтобы "жить" продакшену. Но и настроек по магическим формулам (они обычно либо не приводятся, либо спорны) не хватит и вам еще нужны дополнительные плагины, прокси пуллеры, автопереключалки мастеров и т.д. В документации про это либо объяснено не самым понятным образом, либо первостепенный механизм объясняется мимоходом в описании второстепенного механизма, либо написано что такие-то вещи из коробки сделать нельзя, а про то что надо использовать доп.софт/плагины, но про это в оф.доке не всегда написало. В итоге хорошо структурированную полную информацию найти тяжело и ходишь как по минному полю (запаситесь бекапами и репликой). Зато когда знаешь, работать с этой базой легко и приятно (в отличии от некоторых других где и знание не поможет). Много тулз, много возможностей, гибко настраивается, много удобных инструментов, подходы логичные, внутренности всегда можно посмотреть, производительность отличная и от релиза к релизу все улучшается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

53. Сообщение от keydon (ok), 15-Ноя-21, 22:31	+/–
А что тебе мешает через реплику постгрю обновить? Точно также как и монгу - сначала слейв, потом мастер. Тоже без сучка и задоринки. Формат (CSV) ты сам выбираешь в аргументах, а уязвимости (CVE) оперативно правятся, да и сама постгря частенько (может даже слишком) выпускает новые версии. json наркоманские да, как и сама идея хранить json в sql, походу постгря сама это понимает и идет на это из-за популярности nosql на фоне депопуляризации sql (и не мудрено sql крайне спорная, переусложненная и неэффективная для большинства случаев решение). Банально пытается не остаться никому не нужной. Ну и при всей наркомании оно к тому же и немного сырое, его все улучшают и улучшают. > в голом jdbc это поле считать надо несколько команд Звучит как проблема jdbc, а не постгри
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #57

54. Сообщение от Прохожий (??), 16-Ноя-21, 01:17	+1 +/–
Это вы так "тонко" намекнули, что я читать не умею? Нет, чтобы ссылку на документацию прислать с описанием этой самой архитектуры. Ну чтобы голословным не быть. Или здесь так не принято?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

55. Сообщение от Прохожий (??), 16-Ноя-21, 01:19	+1 +/–
Конечно же всему виной смена СУБД, да? О, эти опеннетные аналитики!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #65

56. Сообщение от Прохожий (??), 16-Ноя-21, 01:22	+/–
С помощью экспорта/импорта? Легко. Другие способы официально не поддерживаются. И?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #62, #63

57. Сообщение от Прохожий (??), 16-Ноя-21, 01:42	+/–
> и не мудрено sql крайне спорная, переусложненная и неэффективная для большинства случаев решение Что за наркоманский бред? Что там спорного и переусложнённого? За месяц-другой осваивается с нуля. Ещё месяц-другой знания шлифуются. Вуаля - вы готовый спец по SQL. > неэффективная... Во времена моей далёкой молодости приходит ко мне мой начальник (он тогда на Клиппере программировал, тогда Клиппер моден был на предприятиях определённой сферы производства), и говорит: "А сделай-ка мне вот такой отчёт". Отчёт представлял собою соединение из нескольких таблиц с последующей фильтрацией. Потом спрашивает, сколько времени нужно для этого, двух-трёх дней хватит? Я отвечаю:"Подождите, пожалуйста, Александр Соломонович, минут десять, сейчас будет готов". Он в шоке. Как!? Я показываю. С того дня мой начальник пошёл учить SQL. Пятьдесят лет было мужику. Но он справился. Приходил иногда за консультациями потом. Других в своём отделе учил. В общем, хотелось бы подробностей, что вы там не осилите никак. Потому что, когда говорят о том, что SQL неэффективен, обычно речь о неосиляторстве идёт, и ни о чём больше. На всякий случай, вдруг вы не знали. SQL - тюринг-полный язык, и ОЧЕНЬ удобный для всяких выборок данных. Даже Гугл, вон, пыжился, пыжился со своей СУБД (изначально noSQL), а потом прикрутил туда всё-таки какой-то урезанный диалект SQL. Но куда Гуглу до анонимного эксперта с Опеннета, можете возразить вы. Да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #58, #71

58. Сообщение от Прохожий (??), 16-Ноя-21, 01:46	+/–
Да. Необходимое уточнение. Я больше с Oracle работал до сих пор. Postgre только-только начал внедряться у нас. Но на первый взгляд выглядит, как Oracle версии 8.0-9.0. То есть, вполне рабочая лошадка, хотя и не без недостатков (по сравнению с Ораклом, у которого своих тараканов вагон и маленькая тележка на самом деле).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

59. Сообщение от Прохожий (??), 16-Ноя-21, 01:51	+/–
> а документацию к существующему сдвг-олимпиадникам осилить сложно Не думаю, что сложно. Думаю, неинтересно. Ну и обычно для крупной компании лучше иметь своё, а не зависеть от чьей-то доброй (злой) воли. Что, собственно, и демонстрируют всякий раз крупные компании. Яндекс - не исключение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

60. Сообщение от Аноноша (?), 16-Ноя-21, 02:54	+/–
> своя система контроля версий (просирает данные) Почему она теряет данные?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #74

61. Сообщение от Аноним (61), 16-Ноя-21, 03:31	+/–
Ну то есть никто раньше не обновлялся, пока обновления шли, переезжать приспичило, когда 10g стала EOL. А потом, да, конечно, кабздец, база не работает, работа встала, начальство грозится уволить... Очень "умно". Ох уж этот русский мужик со своей традицией делать все в посл.момент.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #64

62. Сообщение от Аноним (62), 16-Ноя-21, 07:58	+/–
Собственно и для PG экспорт/импорт все делается легко и непринужденно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

63. Сообщение от ыы (?), 16-Ноя-21, 11:04	+/–
"И" тут заключается в том, что вы такого никогда не делали и как следствие не понимаете проблем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #76

64. Сообщение от ыы (?), 16-Ноя-21, 11:10	+/–
Серьезные решения обычно не представлены в виде самостоятельных сущностей. Как правило сущности тесно связаны и переплетены друг с другом. И матрица совместимости соответственно от одной -двух позиций легко расширяется до 20-30... То есть нельзя обновить ОДИН компонент, например базу. надо обновить все что входит в матрицу совместимостей... ПО, железо... А обновление СУБД и обновление комплекса - это очень разные задачи. Учитывая что каждый компонент после обновления с вероятностью 99% будет глючить уже после того как все по 20 раз протестируют...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #66

65. Сообщение от ыы (?), 16-Ноя-21, 11:14	+/–
Ох уж эти опеннетные коментаторы... В каждый трейд затычки :) По делу то есть что сказать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #75

66. Сообщение от Аноним (61), 16-Ноя-21, 11:30	+/–
Вот я и говорю, вместо того, чтобы составить план перехода на новую версию, пусть через 1-2 версии даже, убедить начальство, прогнать пару раз на тестовом серваке, чтобы очевидные закавыки стали видны, консультироваться с офиц.саппортом (за что деньги уплочены?) и все-таки наконец переехать(да, с опред.головной болью и овертаймами) и получить новые фичи. Нет, надо тянуть до EOL. Молодцы, чо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #68

67. Сообщение от ыы (?), 16-Ноя-21, 11:31	+/–
а вы попробуйте :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

68. Сообщение от ыы (?), 16-Ноя-21, 11:50	+/–
Вы чего-то не поняли мне кажется... Вы знаете что такое матрица совместимости? Это такая штука: Вот у вас есть приложение которое работает на ОС1,  с СУБД1, с Клиентами1, и с ДругимПриложением1 ДругоеПриложение1 работает с другаяОС1,  с ДругаяСУБД1 И вот когда вы захотите обновить ЛЮБОЙ из этих компонент- может оказаться так, что обновить ОДИН компонент- нельзя.  Потому что другие комбинации ОС, СУБД, ПО - неработоспособны. И совместимостей может быть очень, очень много... То есть не " план перехода на новую версию, пусть через 1-2 версии даже, убедить начальство, прогнать пару раз на тестовом серваке" - а разворачивание второго ЦОД, в котором воссоздать инфраструктуру... У вас есть второй ЦОД для тестов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #69, #72

69. Сообщение от ыы (?), 16-Ноя-21, 11:54	+/–
И получается так, что развернуть НОВУЮ структуру (на новом комплексе ПО и железа)- дешевле чем просто "обновить" старую...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #70

70. Сообщение от ыы (?), 16-Ноя-21, 12:01	+/–
А еще же в это второй ЦОД нужен второй комплект лицензий стоимостью как авиалайнер...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

71. Сообщение от keydon (ok), 16-Ноя-21, 15:07	+1 +/–
> За месяц-другой осваивается с нуля. Ещё месяц-другой знания шлифуются. Вуаля - вы готовый спец по SQL. Готовый спец на уровне stackoverflow или университетского курса по базам данным (то есть вообще не спец). На каких-то объемах/задачах это прокатит, но с большой вероятностью через год-два вам придется либо основательно разбираться что, когда, в каких объемах вы пишите и читаете и зачем и переписывать, либо нанимать DBA (который только и делает что оптимизирует базу) со стажем от 2 лет который проанализирует ваши запросы и сделает это за вас, а через полгода опять отрефакторит базу. Спорное что во многих случаях вам не нужно большинство из того что предлагают SQL-базы. Вы быстрее и проще можете и сами обработать данные и закинуть в хранилку с меньшим количеством ограничений. А случаев когда вам действительно все это надо не так много. > С того дня мой начальник пошёл учить SQL. Пятьдесят лет было мужику. Но он справился. Приходил иногда за консультациями потом. Других в своём отделе учил. А кассирше бы и вида консоли хватило, тоже была бы в шоке. > ОЧЕНЬ удобный для всяких выборок данных Настолько удобный что у 100% изучающих SQL возникает диссонанс в голове, люди изобретают PLSQL и непереносимые расширения, а разработчики предпочитают переложить работу на ORM (нередко получая еще больше работы). Да, очень удобно делать простые запросы, но этим тяжело кого-то удивить. Когда начинаются 3-4 вложенности с джойнами даже с комментариями лично мне тяжело сразу понять что творится. Когда удаляешь строки из таблицы на которую ссылаются другие таблицы, а на те в свою очередь ссылаются третьи таблицы, тоже непросто понять что же в итоге ты удалишь, приходится распутывать всю эту схему которую писал не ты. Настолько все это удобно что лично мне проще написать скрипт на питоне который получит простыми запросами данные из таблицы, обработать как нужно и сформировать итоговый запрос. Получается гоораааааздо понятнее и обычно быстрее по времени написания. Но отмечу что я не эксперт по базам, судя по их запасам sql запросов на каждый случай, им норм.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #77, #78

72. Сообщение от Аноним (61), 16-Ноя-21, 21:01	+/–
Да в курсе, в курсе. Но все равно же пришлось переезжать на новую версию, правда? И проходить все это. Только можно ведь было обойтись меньшей кровью, не прыгая с 10 аж на 19. И приобрести бесценный опыт, с которым след.транферы было бы уже проще делать. Но нет, тянули до последнего. Ну тогда не нойте. P.S. Про разные базы и софт - унификацию надо проводить, чтобы была одна экосистема, а не зоопарк.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

73. Сообщение от Онаним (?), 16-Ноя-21, 21:20	+/–
Синий хелпдеск напомнил о покрасневшем синем расчётном кластере :D Ну это если активной мониторилки нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

74. Сообщение от Аноним (74), 17-Ноя-21, 13:17	+/–
из за багов видимо, из за чего же еще?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

75. Сообщение от Прохожий (??), 17-Ноя-21, 22:52	+/–
У вас нелады с логикой. Натягивание совы на глобус - явно не ваш конёк.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

76. Сообщение от Прохожий (??), 17-Ноя-21, 22:56	+/–
Как вы пришли к такому глубокому выводу? Вот недавно тестировали с коллегами как раз такой способ апгрейда. Потому что с 10-ки на 19-ку напрямую апгрейдиться не получится. Только через 11.2.0.4. Но наша база сравнительно небольшая, поэтому решили через экспорт-импорт. Так в чём же там проблемы-то? Ась? Похоже, что вы вообще не в курсе, что так можно. Да? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

77. Сообщение от Прохожий (??), 18-Ноя-21, 00:04	+/–
> то есть вообще не спец Раз уж вы спросили. Я двадцать лет (точнее, уже чуть больше) с Ораклом работаю. Я и есть тот самый DBA (сертифицированный, если что), о котором вы тут разглагольствуете. По совместительству - программист. Работаю с клиентами по всему миру. На всякий случай, потому что вы явно не в теме, но зачем-то пытаетесь выглядеть экспертом. У Оракла, если денег не жалко, есть специальные инструментальные средства, которые вполне сносно (хотя и не во всех возможных случаях) справляются с оптимизацией сложных запросов. 19-я версия даже индексы может за вас построить. А простые запросы щёлкаются оптимизатором как два пальца об асфальт. Главное - свежую статистику вовремя собирать. А вообще все оптимизации запросов сводятся к выяснению количества записей в той или иной таблице,  распределению данных в полях (сколько уникальных значений, а сколько повторяющихся) и способу соединения таблиц. Для упрощения работы СУБД предлагает пользователю план запросов, чтобы он понимал, куда копать дальше. В общем, ничего сложного, от слова совсем. Кто хоть сколь-либо плотно работает с запросами каждый день, и у кого голова на плечах (а не в облаках) - очень быстро способен разобраться, что да как. > Настолько удобный что у 100% изучающих SQL возникает диссонанс в голове Вот зачем вы свой не особо успешный опыт проецируете на всех? Убедительности вашим словам это не добавляет. Просто признайте, что у вас нет таланта к этому занятию (программированию) в целом, и языку в частности. Не ваше это призвание. Это нормально, и ничего обидного здесь нет. > люди изобретают PLSQL PL/SQL изобретён для лучшей модульности, контроля типов и облегчения взаимодействия с внешним миром. SQL - непроцедурный язык. PL/SQL - процедурный. Оба инструмента хорошо дополняют друг друга. > и непереносимые расширения Непереносимые решения создают, потому что вендор хочет привязать вас к своему продукту. Но ведь на современном этапе это обходится. Всякие ORB и тому подобные технологии изобрели как раз для этих целей. Поэтому если изначально подходить грамотно к архитектуре приложения, никаких нерешаемых принципиально проблем с переносом на другую более-менее развитую СУБД не будет. Вы там про Питон упоминаете ниже. Неуж-то не слышали об SQL Alchemy? Вот это одно из таких решений. > Когда начинаются 3-4 вложенности с джойнами даже с комментариями лично мне тяжело сразу понять что творится Если это комментарии в стиле "а вот тут колбаску заворачиваем", то и неудивительно. Уверен, у вас были бы ещё бОльшие проблемы, займись вы разбором какой-нибудь объектно-ориентированной библиотеки классов с тремя-четырьмя уровнями иерархии и множественным наследованием. SQL в этом плане намного проще и прозрачнее. Для того, чтобы с SQL дружить, надо хоть немного алгебру реляционных отношений знать. Также необходимо понимать, что такое множества, какие операции с ними возможны. Ещё важно знать структуру данных, с которыми вы работаете: какие функциональные зависимости между таблицами, как они нормализованы, какая кардинальность у полей. Это то же самое, что для обычного программиста знать алгоритмы и структуры данных. Базовые знания, то есть, для работы с реляционными СУБД. > лично мне проще написать скрипт на питоне который получит простыми запросами данные из таблицы, обработать как нужно и сформировать итоговый запрос Вот тут вы честны, и это правильно, это хорошо. Лично вам - вполне возможно. Вы, вероятно, изначально плохо в языке разобрались, поэтому и барахтаетесь теперь в несистемных обрывках знаний. В итоге занимаетесь г-нокодингом. Обоснование в следующем абзаце. Если ваши таблицы сколь-либо большие, с таким подходом, как ваш, вы напрочь убиваете возможность оптимизировать ваши запросы средствами СУБД. Эффективность оптимизатора здесь будет стремиться к нулю. А это очень плохой подход. Потому что кардинальность ваших таблиц может со временем измениться, и ваши скрипты придётся переписывать по новой, беря в учёт изменившуюся реальность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #79

78. Сообщение от Прохожий (??), 18-Ноя-21, 00:21	+/–
> Спорное что во многих случаях вам не нужно большинство из того что предлагают SQL-базы. Вы быстрее и проще можете и сами обработать данные и закинуть в хранилку с меньшим количеством ограничений. А случаев когда вам действительно все это надо не так много. Вы так говорите, потому что, скорей всего, ничего сложнее простеньких веб-сайтов не писали. Вполне возможно, что такова ваша профессиональная область интересов. Но ещё раз, отучайтесь говорить за всех. Везде, где нужны транзакции, контроль целостности данных и сколь-либо сложные отчёты - везде нужны СУБД с поддержкой SQL. Да взять хоть ту же sqlite. Вы ведь знакомы с этой "хранилкой"? Firefox, например, использует её для хранения своих параметров. А поди ж ты, и там есть поддержка SQL. И это офигенно удобно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #80

79. Сообщение от keydon (ok), 19-Ноя-21, 19:44	+/–
> Раз уж вы спросили. Я двадцать лет (точнее, уже чуть больше) с Ораклом работаю. Я и есть тот самый DBA (сертифицированный, если что), о котором вы тут разглагольствуете. Чувствую меня хотят авторитетом задавить. Ок, я то не DBA и не претендую на истину в последней инстанции. > Работаю с клиентами по всему миру. Я еще студентом работал с клиентами по всему миру, собственно только на студентов такие вещи и срабатывают. > У Оракла, если денег не жалко, есть специальные инструментальные средства Соре, проприетарщина не нужна. > А вообще все оптимизации запросов сводятся к выяснению количества записей в той или иной таблице,  распределению данных в полях (сколько уникальных значений, а сколько повторяющихся) и способу соединения таблиц. Для упрощения работы СУБД предлагает пользователю план запросов, чтобы он понимал, куда копать дальше. В общем, ничего сложного, от слова совсем. Кто хоть сколь-либо плотно работает с запросами каждый день, и у кого голова на плечах (а не в облаках) - очень быстро способен разобраться, что да как. Также просто как нарисовать сову. Если бы эти вещи были также просты как например настроить крон, то не было бы ни DBA, ни художников, а были бы просто "разработчик который сегодня настраивает базу" и "маляр который между покраской забора нарисует Мону Лизу". > Вот зачем вы свой не особо успешный опыт проецируете на всех? Что видел то и пишу. Из моего опыта у 100% людей были проблемы с sql и они встречаются вплоть до опытных разработчиков. Рад за вас если у 100% вашего окружения нет никаких проблем с РБД (и даже если они есть но вы про эти проблемы не знаете). >Убедительности вашим словам это не добавляет. Просто признайте, что у вас нет таланта к этому занятию (программированию) в целом, и языку в частности. Не ваше это призвание. Это нормально, и ничего обидного здесь нет. Перепрофилироваться в гадалку у вас явно не получится, тут вы совсем не убедительны. >  SQL - непроцедурный язык. PL/SQL - процедурный. Оба инструмента хорошо дополняют друг друга. Мы сделаем язык специально для управления данными, стандартизируем его чтобы всем было хорошо, но управлять данными не очень то получается не очень, так что сделаем еще один язык (диалект?). Получается как в ералаше "но чалма не действует вот без этой штуки". > Непереносимые решения создают, потому что вендор хочет привязать вас к своему продукту. Я слышу эту параною с нулевых и она в основном беспочвенна. Если допустить что это правда, вендору гораздо проще отойти от SQL (например аменить одни токены на другие, вместо SELECT заставить писать GET например). Или продолжить использовать свой язык (вроде QUEL). Но этого не произошло. Более того некоторые решения из одних баз потом становятся стандартом что мягко говоря не способствует привязыванию к продукту. А в контексте опенсурса где можно запросто сделать прокси-конвертер (что вы сами признаете) это и вовсе бессмысленно. Ответ напрашивается сам: их делают потому что стандарт (который напомню сделан специально для управления данными для БД) не покрывает необходимые возможности (о чем мы и сами пишите про PSQL). Впрочем не удивалюсь если проприетарный оракл на самом деле так делает - у меня нет причин не доверять сертифицированному эксперту (и пользоваться ораклом и есть кактус). > Поэтому если изначально подходить грамотно к архитектуре приложения, никаких нерешаемых принципиально проблем с переносом на другую более-менее развитую СУБД не будет. "Хорошо делай - хорошо будет", спасибо, кэп. Скажу больше - никаких нерешаемых принципиально проблем никогда не будет (пока они не подходят к ограничениям физики), ведь это всего лишь байтики. > Вы там про Питон упоминаете ниже. Неуж-то не слышали об SQL Alchemy? Вот это одно из таких решений. Во многих наших питоновских сервисах используем. > Если это комментарии в стиле "а вот тут колбаску заворачиваем", то и неудивительно. Да, такое не редкость, но больше как резделитель между разными SQL запросами для разных блоков, что лично я считаю полезным. > Уверен, у вас были бы ещё бОльшие проблемы, займись вы разбором какой-нибудь объектно-ориентированной библиотеки классов с тремя-четырьмя уровнями иерархии и множественным наследованием. SQL в этом плане намного проще и прозрачнее. Внезапно с 4 уровнями иерархии в хорошо написанном коде обычно нет проблем с пониманием, особенно если ЯП под ООП заточен. > Для того, чтобы с SQL дружить, надо хоть немного алгебру реляционных отношений знать. Также необходимо понимать, что такое множества, какие операции с ними возможны. Ещё важно знать структуру данных, с которыми вы работаете: какие функциональные зависимости между таблицами, как они нормализованы, какая кардинальность у полей. Вот именно, чтобы управлять данными приходится схему держать в голове или рисовать самим или надеяться что базу проектировали правильно и напихали во всех необходимых местах constraint с check'ами и тогда просто распутывать эти ограничения пока ошибки не прекратятся. Где-то это и полезно, но нередко лишние (например большинство этих проверок итак сделало приложение получив данные от пользователя и два раза проверять смысла нет). > Это то же самое, что для обычного программиста знать алгоритмы и структуры данных. Базовые знания, то есть, для работы с реляционными СУБД. Только если сильных связей между полями структур будет столько же как между полями таблиц, я выкину этот код нераздумывая. А реляционные базы как будто бы специально сделаны чтобы всем этим зоопарком управлять, но почему мне приходится держать их в голове и распутывать вручную зависимости, я не понимаю. > Вот тут вы честны, и это правильно, это хорошо. Лично вам - вполне возможно. Вы, вероятно, изначально плохо в языке разобрались, поэтому и барахтаетесь теперь в несистемных обрывках знаний. Лично мне, большинству моих коллег, большинству моих коллег на прошлой работе, стажерам, бывшим одногруппникам (некоторые из которых сделали проектирование БД своей дипломной работой что лишний раз подтверждает что это не дело на 5 минут). >  В итоге занимаетесь г-нокодингом. Именно так я себя чувствую когда пишу на SQL какой-нибудь сложный запрос. Можно было бы предположить что я плохой танцор, но это не объясняет почему остальные (кроме DBA и опытных разработчиков) чувствуют себя также. > Если ваши таблицы сколь-либо большие, с таким подходом, как ваш, вы напрочь убиваете возможность оптимизировать ваши запросы средствами СУБД. Эффективность оптимизатора здесь будет стремиться к нулю. Да, я это понимаю и принимаю. Но как правило это экономит мое время (хотя казалось бы должно быть наоборот), я избегаю магию оптимизатора и уверен что добавление еще одного поля магическим образом не увеличит время выполнения в 10 раз (что неоднократно случалось). А то как я обрабатываю данные, мной контролируется. Я могу просто писать код привычным для себя образом не утруждая себя запоминанием волшебных оптимизаций для конкретных БД (которые возможно перестанут быть актуальны в следующем релизе БД, еще один камень в копилку "универсального" стандарта SQL). Справедливости ради замечу что мои десятки запросов очевидно менее эффективны в контексте нагрузки на базу чем один грамотно подготовленный мегазапрос, но учитывая количество остальных запросы и то что мои запросы не носят периодический характер, это капля в море, а времени мне экономит изрядно. > Потому что кардинальность ваших таблиц может со временем измениться, и ваши скрипты придётся переписывать по новой, беря в учёт изменившуюся реальность. Как раз нет. По-моему способу когда я делаю множество простых запросов в (основном) одну таблицу, связи между таблицами меня меньше всего интересуют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #81

80. Сообщение от keydon (ok), 19-Ноя-21, 20:28	+/–
> Вы так говорите, потому что, скорей всего, ничего сложнее простеньких веб-сайтов не > писали. Вполне возможно, что такова ваша профессиональная область интересов. Все таки вам не быть вангой. >Но ещё раз, отучайтесь говорить за всех. Вы серьезно? Вот наш разговор: -"Бывают ситуации когда реляционные базы не нужны" -"Отучитесь говорить за всех" (т.е. нет, таких ситуаций не бывает) > Везде, где нужны транзакции, контроль целостности данных и сколь-либо сложные отчёты - Да, только вот не везде они нужны и не везде в полном объеме. А про отчеты вообще лишнее, не понятно к чему вы их приплели. Никто не мешает использовать встроенную БД без поддержки SQL с транзакциями и контролем целостности. И эта БД даже не обязательно должна быть реляционной. > нужны СУБД с поддержкой SQL. Строго говоря нет, но практически это не важно. > Да взять хоть ту же > sqlite. Вы ведь знакомы с этой "хранилкой"? Firefox, например, использует её > для хранения своих параметров. А поди ж ты, и там есть > поддержка SQL. И это офигенно удобно. В чем логика? Наличие "удобной" встроенной базы с поддержкой SQL, которую используют в браузере должно что-то доказывать? Видимо тут комбинация из двух типичных логических ловушек - раз используется в известном продукте, значит используют все/эксперты, а все/эксперты не могут ошибаться, но это даже на детей не всегда действует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #82

81. Сообщение от Прохожий (??), 21-Ноя-21, 14:26	+/–
> Я еще студентом работал с клиентами по всему миру, собственно только на студентов такие вещи и срабатывают. У меня такое ощущение, что вы недалеко от студенчества ушли. Может, ошибаюсь. > Также просто как нарисовать сову. Когда речь идёт о небольшом количестве запросов - очень просто. Сложность возникает с ростом их количества. > Мы сделаем язык специально для управления данными, стандартизируем его чтобы всем было хорошо, но управлять данными не очень то получается не очень, так что сделаем еще один язык (диалект?). Получается как в ералаше "но чалма не действует вот без этой штуки". PL/SQL - универсальный язык, который не столько для управления данными нужен, сколько для выполнения других задач. SQL - узкоспециализированный язык исключительно для управления данными. Не вижу никаких ералашей. > Перепрофилироваться в гадалку у вас явно не получится, тут вы совсем не убедительны. Ваши высказывания просто очень красноречивы. Я лишь немного подытожил, не более. > Я слышу эту параною с нулевых и она в основном беспочвенна. Если допустить что это правда, вендору гораздо проще отойти от SQL (например аменить одни токены на другие, вместо SELECT заставить писать GET например). Или продолжить использовать свой язык (вроде QUEL). Но этого не произошло. У Оракла того же свой диалект SQL. Аналогов нет. У остальных производителей СУБД та же или похожая ситуация. Да, в целом все стремятся поддерживать стандарты. Но, как в том анекдоте "есть нюансы". > стандарт (который напомню сделан специально для управления данными для БД) не покрывает необходимые возможности (о чем мы и сами пишите про PSQL) PL/SQL для всех остальных задач, не для управления данными. Для управления данными - SQL. > "Хорошо делай - хорошо будет", спасибо, кэп. Всегда, пожалуйста. Просто многие забывают, что для того, чтобы делать хорошо, надо ещё знать немного побольше, чем основы. Но некоторые и основ не знают, и сразу в бой. Вот и получается в итоге, что надо постоянно рефакторингом структуры данных заниматься. Люди в таких проектах часто на интуицию пытаются полагаться, которая их всегда в итоге подводит. Это, как если бы студент какой сразу сел за написание кода с использованием любого языка программирования, не ознакомившись предварительно с существующими тонкостями, практиками, методологией. В итоге появляются книги, вроде "Совершенный код", которые учат жизни таких вот горе-специалистов. При работе со сложными структурами данных - то же самое соображение верно. > Из моего опыта у 100% людей были проблемы с sql и они встречаются вплоть до опытных разработчиков. Из моего опыта у этих людей до тех пор такие проблемы наблюдаются, пока они не возьмут хоть какую-то книжку по SQL, и не попытаются её хотя бы прочитать. Многие, видя простенькие SQL-запросы на каком-нибудь сайтике-обучалке, ошибочно полагают, что они уже всё знают, и больше им ничего не нужно. А некоторые вообще считают, что им SQL знать не нужно - за них прокси всё будет делать. На таких я насмотрелся за свою жизнь. Но ведь это отнюдь не означает, что SQL - суперсложен в изучении и последующем использовании. > Внезапно с 4 уровнями иерархии в хорошо написанном коде обычно нет проблем с пониманием Внезапно есть. Встречались книги от авторитетных авторов, где не рекомендовались иерархии более двух-трёх уровней - людям очень тяжело бывает разобраться, откуда появился тот или иной метод или свойство. А уж когда множественное наследие применяется - то и подавно. > Вот именно, чтобы управлять данными приходится схему держать в голове А вы как хотели, интересно? Почему-то 4 уровня иерархии в ООП для вас не проблема, хотя там тоже все классы надо в голове держать, чтобы понимать, что происходит. И вы не сможете разобраться в такой иерархии, пока не прошерстите весь код, который и в разных модулях может находиться. А SQL-запрос, в котором сцепка всего из четырёх таблиц (причём все таблицы явно указаны в тексте запроса, включая метод сцепки) - проблема. Где логика? > Только если сильных связей между полями структур будет столько же как между полями таблиц, я выкину этот код нераздумывая. Сильная связь - это, например, связь заголовка накладной с табличной частью? А как ещё избежать лишних данных при их хранении? Или всё в одну таблицу запихнуть предлагаете? Такой метод подойдёт, если данные не меняются - часто денормализация используется в хранилищах для ускорения работы запросов. А если меняются - задолбаетесь дополнительные проверки целостности писать. Но допустим, вы объекты имеете ввиду. Как потом отчёты строить по вашей объектной структуре данных? Циклами? В таком случае, вы ничем не отличаетесь от моего начальника на той стадии, когда он не знал SQL и на простенький отчёт предлагал потратить 2-3 дня. > А реляционные базы как будто бы специально сделаны чтобы всем этим зоопарком управлять, но почему мне приходится держать их в голове и распутывать вручную зависимости, я не понимаю. Нормализация таблиц (управление которыми вы назвали зоопарком) нужна для упрощения контроля целостности данных, при условии, что такие данные часто меняются. Обычно достаточно создать primary key, foreign key, навешать простенькие constraints, и СУБД сама будет всё контролировать вместо программиста, которому в противном случае пришлось бы писать простыни кода. > это не дело на 5 минут Это дело нескольких месяцев полноценного обучения. Да, я об этом уже говорил ранее. Но так в любой профессии. Странно, что вы акцент сделали именно на SQL при этом. > Но как правило это экономит мое время (хотя казалось бы должно быть наоборот) Это потому, что вы до сих пор не разбираетесь в SQL, вы его до сих пор не освоили, в чём сами же и признались. Попробуйте его всё-таки освоить. И тогда ваша жизнь будет куда проще и может даже приятней нынешней, где вы в каждой вашей портянке кода по новой изобретаете велосипед. > не утруждая себя запоминанием волшебных оптимизаций для конкретных БД Это очень редко когда надо делать на практике на самом деле. При условии, что изначально структура БД проектировалась не вчерашним студентом, само собой. > мои десятки запросов очевидно менее эффективны в контексте нагрузки на базу чем один грамотно подготовленный мегазапрос Всего лишь ОДИН из ваших запросов при сканировании большой таблицы в параллели вполне может ухайдокать сервер. > связи между таблицами меня меньше всего интересуют Но вы же где-то потом соединяете все эти надёрганные то здесь, то там, кусочки данных вместе? Для этого вам приходится писать дополнительный код, тратить на это драгоценное время, которое вы якобы экономите.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

82. Сообщение от Прохожий (??), 21-Ноя-21, 14:43	+/–
> Да, только вот не везде они нужны и не везде в полном объеме. Соглашусь. Поэтому я специально перечислил случаи, где всё-таки нужны. А что такое "в полном объёме"? Это как? Не со всей имеющейся функциональностью? Ну с этим никто не спорит как бы. > А про отчеты вообще лишнее, не понятно к чему вы их приплели. Потому что сам по себе сбор данных не имеет никакого смысла. Их (данные) обычно собирают для последующего анализа. > Никто не мешает использовать встроенную БД без поддержки SQL с транзакциями и контролем целостности. И эта БД даже не обязательно должна быть реляционной. Пример такой СУБД? Чтобы и с транзакциями, и с контролем целостности, и без поддержки SQL? В данном случае без попытки поддеть. В мире много СУБД, и я далеко не о всех о них знаю. > В чем логика? Наличие "удобной" встроенной базы с поддержкой SQL, которую используют в браузере должно что-то доказывать? Точно. Раз ею пользуются, причём не только в FF, и в Хроме и ещё много где, это УДОБНО! Иначе бы не пользовались. В этом и логика. > значит используют все/эксперты Где вы усмотрели функтор всеобщности, остаётся только догадываться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #83

83. Сообщение от keydon (ok), 22-Ноя-21, 22:37	+/–
> Потому что сам по себе сбор данных не имеет никакого смысла. Их (данные) обычно собирают для последующего анализа. Мелкие проекты могут без OLAP обойтись. > Пример такой СУБД? Чтобы и с транзакциями, и с контролем целостности, и без поддержки SQL? libmdbx например https://www.opennet.ru/opennews/art.shtml?num=55949 > Точно. Раз ею пользуются, причём не только в FF, и в Хроме и ещё много где, это УДОБНО! Иначе бы не пользовались. В этом и логика. Много смелых предположений. Что например может быть неверным: 1) Пользуются из-за удобства 2) Неудобным не пользуются 3) Популярность ("много где") и неудобство несовместимы 4) Удобство означает нужность в случае если "нужны транзакции, контроль целостности данных и сколь-либо сложные отчёты" Попробую провести аналогию (конечно же плохую, как и все аналогии): "Когда хочется есть [нужны транзакции, контроль целостности данных и сколь-либо сложные отчёты], съедают яблоко [используют sql]. Взять например Васю [sqlite]. Он каждый день ест яблоки [поддерживает sql], все знают Васю [sqlite много где используют], Вася говорит что яблоки его любимая еда и Валеры тоже. Если голодны, ешьте только яблоко". > Где вы усмотрели функтор всеобщности, остаётся только догадываться. Мне и до "используется в файрфоксе, значит удобно" пришлось додумывать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #84

84. Сообщение от Прохожий (??), 23-Ноя-21, 12:54	+/–
> Мелкие проекты могут без OLAP обойтись. Мы обсуждали SQL, а не OLAP. Это во-первых. Во-вторых, я изначально и говорил, что очень похоже, что вы ничего сложнее простеньких сайтов (ну или каких-то внутренних продуктов аналогичной сложности) не писали. Речь, конечно, о тех программах, которые призваны работать с данными со сложной структурой и с большим набором записей, а не вообще о любых. > libmdbx например https://www.opennet.ru/opennews/art.shtml?num=55949 Эта СУБД не предусматривает какой-либо последующий анализ собранных данных, судя по всему. Поэтому и SQL там нет. Но ок, она подходит под требование "наличие транзакций". Однако не увидел там возможности контроля целостности данных (это не возможность восстановления БД после сбоев, я имел ввиду проверку на  логическую целостность (непротиворечивость) данных на этапе их получения извне). > Много смелых предположений. Что например может быть неверным: > 1) Пользуются из-за удобства Полагаете, разработчиков Хрома, ФФ кто-то извне заставлял пользоваться sqlite? Или они поголовно все идиоты? Нет, такое возможно, конечно, но крайне маловероятно. > 2) Неудобным не пользуются > 3) Популярность ("много где") и неудобство несовместимы Обычно так и есть (исключения - какие-то ограничения и/или низкая квалификация персонала). Если люди выбирают тот или иной инструментарий, причём массово, это означает, что альтернативы нет. Раз нет альтернативы, то можно сделать вывод, что по сравнению с её отсутствием, пользоваться таким инструментом удобно, чем не иметь такого инструмента вообще. Но при этом никто не утверждает, что подобный инструмент вообще свободен от каких-либо недостатков. То есть, речь идёт об относительном удобстве, а не абсолютном. >  4) Удобство означает нужность в случае если "нужны транзакции, контроль целостности данных и сколь-либо сложные отчёты" Удобство означает эффективность (высокая производительность, малые трудозатраты) работы при всех обозначенных выше ограничениях. Обычно эффективность обуславливает нужность, если только нет влияния со стороны ("партия сказала нужно, комсомол ответил "есть"). > Попробую провести аналогию (конечно же плохую, как и все аналогии) Вы в своей аналогии не учитываете критерии, которые делают sqlite уникальным в своём роде инструментом. Яблоки - не уникальная еда. Поэтому соглашусь, ваша аналогия неудачна. Но не соглашусь, что все аналогии неудачны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

85. Сообщение от RNZ (ok), 11-Июл-22, 01:32	+/–
>> Вот так: >> $ for h in {01,02,03}; do ssh vm$h-prod pgrep -c postgres; done >> 5130 >> 5122 >> 5198 > И потом kill -9 адресно по пидам, угу. И где вы там пиды увидели? > Ну и именование... vm0x-prod - похоже на какой-то колхозный сохошный локалхост. Мозг не позволяет допустить, что приведённое именование кастрировано до "обезличенного"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

86. Сообщение от RNZ (ok), 11-Июл-22, 01:33	+/–
> а чо не > ssh vm{01,02,03}-prod pgrep -c postgres > ? > Ти что тебе даёт знание этих пидов? Нет там пидов, rtfm -> man pgrep.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

87. Сообщение от RNZ (ok), 11-Июл-22, 01:43	+/–
> а чо не > ssh vm{01,02,03}-prod pgrep -c postgres > ? Потому-что: for h in {01..05}; do echo -n "$h: "; ssh root@vm$h-prod pgrep -c postgres; done 01: 2568 02: 2592 03: 2568 04: 2548 05: 2561
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

88. Сообщение от RNZ (ok), 12-Июл-22, 12:34	+/–
> balancer.web.kb.sw.xen4 > http1.web.kb.us.xen1 > http2.web.kb.sw.xen4 > mysql1.galera.kb.us.xen1 > mysql2.galera.kb.sw.xen4 > garb.galera.kb.ru.xen2 > ocfs2-arb.iscsi.kb.ru.xen2 Ненужная смена fqdn при перемещении vm/ct в другой регион или хост... Плюс ахтунг с ssl... По мне более практичный fqdn следующий: abbrN-stage-prj.sld.tld.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #89, #90

89. Сообщение от Онаним (?), 12-Июл-22, 12:59	+/–
В данном случае подразумевается, что vm/ct между регионами не переносятся, если пригорело - вместо них деплоятся дополнительные. И даже между пулами гипервизоров не переносятся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

90. Сообщение от Онаним (?), 12-Июл-22, 13:00	+/–
Потому что для переноса из региона надо живую сеть, живой пул и живую хранилку в регионе, а состояние "пригорело" - это обычно когда уже полностью нарушено одно из этих условий, да и сдеплоить в условиях дублирования данных быстрее, чем перенести.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #91

91. Сообщение от RNZ (ok), 12-Июл-22, 15:22	+/–
> Потому что для переноса из региона надо живую сеть, живой пул и > живую хранилку в регионе, а состояние "пригорело" - это обычно когда > уже полностью нарушено одно из этих условий, да и сдеплоить в > условиях дублирования данных быстрее, чем перенести. Нумерация контейнеров достаточна для принятия решений когда "пригорело". А перенос может быть обусловлен необходимостью (легаси, финансовая политика, вывод из эксплуатации хоста под другие задачи).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #92

92. Сообщение от Онаним (?), 12-Июл-22, 18:51	+/–
Перенос из региона в регион обычно требует изменения не только DNS-имени, но и ряда прочих параметров, так как регионы не эквивалентны. В случае вывода пула да, возможны варианты, когда придётся DNS-имя менять, но это всё очень редкие и очень частные случаи. К тому же пул обычно не просто выводится, а замещается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема