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

Релиз СУБД PostgreSQL 14, opennews (?), 30-Сен-21, (0) [смотреть все] Пора переводить прод с мускула на постгрю , menangen (?), 19:58 , 30-Сен-21, (1) +11   // А у этот комеент вызывает подозрения что вы не вкурсе как писать переносимые и р, кукурузка (?), 20:40 , 30-Сен-21, (8) +4   // Хм, тут как спросишь, какую СУБД выбрать в проект, так сразу начинается - смотр, Аноним (16), 21:33 , 30-Сен-21, (16) +11   У товарища просто примитивный бэкенд и задачи Соответственно там и отличий ника, Аноним (25), 22:17 , 30-Сен-21, (25) +2   Делают, почему же не делают Только делают там где понимают, нахрена ж страдать, пох. (?), 23:05 , 30-Сен-21, (32) –2   У тебя похоже вообще задач нет, одни смузи на уме , Аноним (48), 03:29 , 01-Окт-21, (48)   Смотря КАКАЯ ЛИЦЕНЗИЯ 300 местных далба обов пишет для собственной бабушки, , Умпа (?), 02:01 , 01-Окт-21, (45) –3   Там наверное select password from wp_users where username vasya , Steve Ballmer (?), 11:51 , 01-Окт-21, (84) +1   Мамкиным понторезам не лень 2k21 вместо 2021 набирать , 2021 (?), 22:05 , 30-Сен-21, (22) +10   Папкиным манторезам не лень 2021 вместо 2021 набирать , Аноним (16), 22:17 , 30-Сен-21, (26) –2   Ну они сейчас достаточно быстрые На прошлом проекте в базу никто практически ни, Аноним (25), 22:19 , 30-Сен-21, (27)   2k21 2210 2021, Счетовод (?), 08:01 , 01-Окт-21, (61)   А тебя не обламывает раскладку переключать ради забивания k Ты тратишь впустую , Аноним (89), 12:10 , 01-Окт-21, (89) +1   Дело не в твоём времени, а в том что твой текст выглядит плохо, неприятно читать, Аноним (108), 16:36 , 01-Окт-21, (108) +2   лавров jpg, мимокро (?), 20:21 , 01-Окт-21, (124)   2k во всём мире значит 2000 И это правильно Двадцать с лишним лет назад умный че, Аноним (128), 01:37 , 02-Окт-21, (128)   Сопротивление среднего резистора 2002 Ом или все же 2200 Ом https encrypted-tb, ptr128 (?), 07:23 , 02-Окт-21, (131) +1   Падаван явно мал и глупУ разных реализаций разный синтаксис То, что в Oracle зо, kai3341 (ok), 22:33 , 30-Сен-21, (28)   вместо счетчика использовать свой генератор айдишек базирующийся на времени или, kissmyass (?), 22:48 , 30-Сен-21, (31) –2   Очень умная идея Привет, фрагментация кластерного индекса и всей таблицы, развл, kai3341 (ok), 23:28 , 30-Сен-21, (36) –2   Скрыто модератором, kissmyass (?), 00:44 , 01-Окт-21, (41) +2   Скрыто модератором, kai3341 (ok), 03:19 , 01-Окт-21, (46) –2   Скрыто модератором, aa (?), 07:03 , 01-Окт-21, (56) +2   Скрыто модератором, Bx (ok), 07:16 , 01-Окт-21, (59) +2   Скрыто модератором, edo (ok), 06:21 , 02-Окт-21, (130)   Обсмеялсо , Аноним (48), 03:32 , 01-Окт-21, (49) +1   Мягко скажем, винегрет , Наме (?), 10:20 , 04-Окт-21, (167)   Все нормальные люди используют orm а не пишут sql запросы и кот полностью перено, Аноним (40), 00:09 , 01-Окт-21, (40) –4   Все нормальные люди используют комбинацию подходов используют ORM и Query Build, Аноним (68), 08:59 , 01-Окт-21, (68) +3   Открой для себя SQLAlchemy Эта ORM позволяет извлечь как все преимущества импер, kai3341 (ok), 12:21 , 01-Окт-21, (91) –2   А как там rollbacks-ы отрабатывают Вот налепил ты объектов, решил их транзакцио, Наме (?), 12:29 , 01-Окт-21, (93)   Отрабатывает Только я избегаю использовать ActiveRecord, kai3341 (ok), 18:10 , 01-Окт-21, (118)   Не надо лепить объекты по принципу ActiveRecord для проектов сложнее бложика с к, Аноним (68), 10:20 , 02-Окт-21, (138)   внезапно, мир не ограничен петоном и даже в мире питона этих орм штук 10, наприм, 3 (?), 14:20 , 01-Окт-21, (104)   Количество качество С джангой сравнил Сравнил бы в knex -- был бы другой раз, kai3341 (ok), 18:13 , 01-Окт-21, (120)   SQLAlchemy прекрасный ORM, один из лучших среди всех языков Но даже на нём напи, Аноним (108), 16:40 , 01-Окт-21, (109)   Писал запросы на пару экранов Не испытал мучения, а наоборот, писал с удовольст, kai3341 (ok), 18:11 , 01-Окт-21, (119)   SQLAlchemy прекрасна Но ее прекрасность обусловлена особенностями Питона, на др, Аноним (68), 10:18 , 02-Окт-21, (137)   Сейчас, в общем-то, не важно как составлен запрос, если он логически корректен , Наме (?), 12:30 , 01-Окт-21, (94)   Как раз важно Есть 100500 способов составить запрос, получив на выходе один и т, kai3341 (ok), 18:18 , 01-Окт-21, (121)   Стратегия извлечения в нормальной СУБД будет зависеть от оптимизатора запросов, , Прохожий (??), 05:12 , 03-Окт-21, (149) +1   Святая наивность Не похоже, что вы хоть раз писали SQL запросы сложнее SELECT , kai3341 (ok), 15:53 , 03-Окт-21, (161)   Это вы мне говорите, человеку с 20-летним стажем работы с СУБД Да, изначально оп, Прохожий (??), 20:29 , 05-Окт-21, (169)   FYI стаж экспертизаКак бы да Когда сам знаешь, где разбросаны грабли, ты их, kai3341 (ok), 21:56 , 05-Окт-21, (173)   если ты думаешь, что в риал ворлде с тм кто-то настолько заморачивается, что , mos87 (ok), 07:58 , 01-Окт-21, (60) +1   Возьмём, например, 1С Несколько мне известно, их продукт работает в реальном ми, Прохожий (??), 05:17 , 03-Окт-21, (150)   Насколько мне известно там постгрес но вполне может статься что бывает и разное , mos87 (ok), 10:51 , 03-Окт-21, (158)   Смотреть в сторону ORB , Прохожий (??), 20:20 , 05-Окт-21, (168)   зачем и что это , mos87 (ok), 20:32 , 05-Окт-21, (170)   Object Relational Bridge Зачем смотреть Есть у вас сложный продукт, который одн, Прохожий (??), 20:37 , 05-Окт-21, (172)   Ну если у тебя SQL это тупой Store без хранимых процедур и ты слово профайлер сл, letsmac (ok), 09:45 , 01-Окт-21, (71) +2   Это ваше переносимое и расширяемое , если ему пофиг на транзакционное ядро, кот, Наме (?), 11:10 , 01-Окт-21, (77)   А варианты Хотите приведу целый ряд запросов, которые вообще без изменений легк, ptr128 (?), 07:49 , 02-Окт-21, (135)   нооо мооой прооот свитый из багов и сноввсем моим бедам назлововсе не так уж пло, й (?), 23:17 , 30-Сен-21, (34) +5   // Оо подошли старперские оптимизации бесконтактного боя, Док (?), 12:19 , 02-Окт-21, (139) –1   зачем , kissmyass (?), 21:49 , 30-Сен-21, (19) –1   Пора тебе побеспокоиться за свой тыл , Аноним (48), 03:27 , 01-Окт-21, (47)   Не стоит Но стоит задуматься о создании нового прода уже на PostgreSQL Я не ос, FSA (??), 20:43 , 01-Окт-21, (125) +1   Слоник - это вещь Моё уважение проекту , InuYasha (??), 20:01 , 30-Сен-21, (2) +5 Надеюсь до постгри раст не доберется , Аноним (89), 20:02 , 30-Сен-21, (4) // А было бы неплохо, повышение качества еще никому не вредило, Аноним (6), 20:11 , 30-Сен-21, (6) –5 // Переписывание затянется в бесконечность , Аноним (7), 20:24 , 30-Сен-21, (7) –1 Посмотрите сколько пунктов в стандарте MISRA Память лишь один пункт из многих , Аноним (11), 20:56 , 30-Сен-21, (11) +4 // Расту стандарт не нужен, там можно как попало написать, если скомпилировалось - , Аноним (12), 21:04 , 30-Сен-21, (12) +1 Зато на Расте синтаксис подталкивает к тому чтобы писать говнокод А говнокод мо, Аноним (17), 21:33 , 30-Сен-21, (17) –2 Mozilla, помню, говорила обратное 129300 , leap42 (ok), 05:38 , 01-Окт-21, (52) –1 Посмотрите внимательней на требования MISRA и список тех, кто этой MISR е следуе, Анонн (?), 21:31 , 30-Сен-21, (14) +1 Это хорошо или плохо , Аноним (69), 09:17 , 01-Окт-21, (69) –2 С точки зрения надежности - плохо Но есть мнения что ядро какое оно сейчас вооб, Анонн (?), 12:10 , 01-Окт-21, (88) +2 В этом проекте на С с качеством все в порядке Давайте не портить его rust уже в, An (??), 12:38 , 01-Окт-21, (96) +2 Все давно придумано за вас И да, есть , Alladin (?), 00:05 , 03-Окт-21, (146) чо за постгри , Аноним (105), 15:01 , 01-Окт-21, (105) –2 Отличный проект Успехов , кукурузка (?), 20:41 , 30-Сен-21, (9) +2 Бредовый синтаксис У них всегда были с этим проблемы и вот опять , Аноним (10), 20:52 , 30-Сен-21, (10) –2 // почему этот нереально жырный и унылый троллинг не удаляется троллботнумшаблон н, mos87 (ok), 08:19 , 01-Окт-21, (64) –3 у постгреса похоже в штате больше форумных ботов, чем прогеров иначе я прост, лютый жабби__ (?), 11:08 , 01-Окт-21, (76) –2 // Может быть проблема в тебе, что если ты не прав, не приходило такое в голову , Аноним (108), 16:43 , 01-Окт-21, (110) –1 // не думаю в могучем слоне всё так же - если на диске занято больше 60 то vacuum , лютый жабби__ (?), 07:41 , 02-Окт-21, (132) +1 Уже обновился на Убунте Теперь еще численные типы могут содержать значение Infi, Аноним (13), 21:21 , 30-Сен-21, (13) Мастер-Мастер подвезли Нет Тогда сразу в гарбедж , Аноним (17), 21:31 , 30-Сен-21, (15) –6 // лол, зочем он же ничего кроме боли не дает, leap42 (ok), 05:40 , 01-Окт-21, (53) +2 тебе твой мастер не нравится слишком белый , mos87 (ok), 08:17 , 01-Окт-21, (63) +2 // Ему тройничок подавай, Аноним (92), 12:28 , 01-Окт-21, (92) finally , One More Аноним (?), 22:36 , 30-Сен-21, (29) +2 vacuum full надеюсь наконец-то запретили и объявили окончательно и бесповоротно , пох. (?), 23:06 , 30-Сен-21, (33) –1 // А смысл , Аноним (50), 04:40 , 01-Окт-21, (50) +1 Нужное Разрешаю дальнейшую разработку А то тут некоторые повадились ненужное бе, PetrG (ok), 23:22 , 30-Сен-21, (35) –1 // Зачем спрашивать у вас разрешение, вы кто дядя , Alladin (?), 00:06 , 03-Окт-21, (147) // Q E D Хочу opennet но для взрослых За был этот десткий сад в комментариях , petrg (ok), 22:30 , 03-Окт-21, (165) –1 А по моему хорошая шутка получилась , petrg (ok), 22:31 , 03-Окт-21, (166) Ещё никто не спрашивал про пакеты и undo , Аноним (37), 23:29 , 30-Сен-21, (37) // Подобие пакетов есть Подобие анду-сегментов тоже есть Но больше похоже на верс, Наме (?), 11:29 , 01-Окт-21, (81) Ну наконец-то каждый раз при установке не придётся это ручками изменять, ждал эт, Ilya Indigo (ok), 00:06 , 01-Окт-21, (38) –2 А чем старый не устроил SELECT FROM test WHERE details- attributes - size , Ilya Indigo (ok), 00:09 , 01-Окт-21, (39) –3 // Фронтендеры пугаются , Аноним (50), 04:42 , 01-Окт-21, (51) –2 // Что фронтендеры вообще в SQL-е забыли, с ним работают только бекеры , Ilya Indigo (ok), 10:26 , 01-Окт-21, (72) +1 // Javascript теперь и на беке давно - , Аноним (108), 16:48 , 01-Окт-21, (111) –1 Более читабельный Это уже наркомания какая-то SELECT FROM test WHERE details-, Фёдор (?), 07:05 , 01-Окт-21, (57) +1 // пихать в скуль вот это всё - это и есть наркоманияскуль придуман для относительн, mos87 (ok), 08:21 , 01-Окт-21, (65) // Декларативные не равно простенькие Коррелированные подзапросы с окнами и свёртк, Наме (?), 11:16 , 01-Окт-21, (78) +2 само собой, ибо вся мякотка скрыта в СУБДно они и обычно в хвосте переносимости , mos87 (ok), 12:26 , 02-Окт-21, (141) Особенно невозможность разименовать json b в которой нужно оборачивать сравнива, Ilya Indigo (ok), 10:28 , 01-Окт-21, (73) У этих операторов разный тип результата - json, - text , а у оператора индек, Аноним (108), 16:51 , 01-Окт-21, (112) Почему же, - как в php , Alladin (?), 00:07 , 03-Окт-21, (148) Мне интересно, как эта наркомания вообще пролезла в когда-то человекочитаемый sq, edo (ok), 00:08 , 02-Окт-21, (127) +1 Я, если честно, вообще не знаю, зачем до сих пор нужен SQL, если в него приходит, Аноним (55), 06:58 , 01-Окт-21, (55) // Уже есть встроенные языки plsql, perl, , m (??), 07:09 , 01-Окт-21, (58) +2 // да, это просто традиция что ДБшники как секта всё пихают в свою СУБД и ограничен, mos87 (ok), 08:24 , 01-Окт-21, (66) // У СУБД свои задачи, у фронтэнда и контроллеров -- свои Манипулировать данными в, Наме (?), 11:24 , 01-Окт-21, (80) +1 да, но бизлогика на скуле - это неуправляемая messя лично за то чтобы сырые данн, mos87 (ok), 12:42 , 02-Окт-21, (142) +1 Мне это не нужно,я этого не понимаю Значит никто не понимает и никому этотне ну, Alex (??), 10:57 , 01-Окт-21, (74) +1 Потому что в Сиквеле двумя фразами можно сделать то, что на императивных языках , Наме (?), 11:18 , 01-Окт-21, (79) Оракуль пытался, ещё с 90-х Чё-т не очень жаба SQL или хотя бы PL SQL заменила, nobody (??), 11:56 , 01-Окт-21, (85) // Сиквел ничем не заменить ПЛ хорошо подружен с Сиквелом А Ява -- она не для зам, Наме (?), 12:04 , 01-Окт-21, (86) Java давно есть https github com tada pljavaНо заменить SQL она все равно не в, ptr128 (?), 07:54 , 02-Окт-21, (136) Зачем все это в SQL DB , pofigist (?), 09:43 , 01-Окт-21, (70) // Для функциональности , Аноним (108), 16:52 , 01-Окт-21, (113) // Какое отношение имт все эти свистгперделки к функционалу SQL DB , pofigist (?), 19:37 , 03-Окт-21, (164) Чтобы не таскать данные между базой и чем-то ещё по сети туда-сюда, Яхз (?), 23:41 , 01-Окт-21, (126) о мама мия почему эти люди не могут посмотреть как сделано у нормальных людей, лютый жабби__ (?), 11:04 , 01-Окт-21, (75) –3 // API на javascript Как вы себе представляете добавление javascript в SQL , Аноним (108), 16:58 , 01-Окт-21, (114) –2 // это какое-то гомно из 70-х прошлого века Зачем за него цепляться , лютый жабби__ (?), 07:43 , 02-Окт-21, (133) // Да будет тебе известно, что это из 70-х снабжается математическим аппаратом и во, Прохожий (??), 05:39 , 03-Окт-21, (151) После добавления в монгодб транзакций, постгрес стал официально не нужен , МояВенда (ok), 11:42 , 01-Окт-21, (82) –4 // Монго давно умер И нет там никаких транзакций и быть не может в принципе , Наме (?), 12:05 , 01-Окт-21, (87) +3 // Я аш смузи подавился Вы все врёте , Аноним (99), 13:19 , 01-Окт-21, (99) +2 С сайта монги MongoDB 5 0 is the latest generation of the database most wanted, МояВенда (ok), 13:59 , 01-Окт-21, (101) –1 // На сарае еще и не такое написано, но там - дрова , пох. (?), 14:04 , 01-Окт-21, (103) +2 чо за постгре , Аноним (105), 15:02 , 01-Окт-21, (106) +1 Афира почитайте, а то может оказаться что транзакции не совсем транзакционны как, Аноним (108), 17:00 , 01-Окт-21, (115) глупый слонопотамщик не понимает, что в монге данные немного по другому хранятся, лютый жабби__ (?), 16:16 , 01-Окт-21, (107) –3 // https aphyr com tags mongodbТранзакции не имеют никакого отношения к тому как , Аноним (108), 17:05 , 01-Окт-21, (116) +2 Причем тут вообще файлы Монго гарантирует атомарность на уровне документа или , МояВенда (ok), 17:38 , 01-Окт-21, (117) Транзакции в 99 случаев не нужны Либо нужны, но тормозят больше чем нужно , лютый жабби__ (?), 07:47 , 02-Окт-21, (134) –2 Ты в каком-нибудь банке не ляпни подобную глупость на собеседовании только Не п, Прохожий (??), 05:44 , 03-Окт-21, (152) +1 Ну почему каком-нибудь Скорее всего в Сбербанке Он под себя подомнет весь И, ыы (?), 11:51 , 03-Окт-21, (160) А ты не ляпни про постгрес на собеседовании в банке , лютый жабби__ (?), 18:51 , 03-Окт-21, (162) –2 Иногда стоит промолчать а не демонстрировать уровень своей компетентностиhttps , ыы (?), 19:17 , 03-Окт-21, (163) А вы уверены что транзакций там нет Может вам просто предоставляют механизм нек, ыы (?), 11:50 , 03-Окт-21, (159) Респект, Аноним12345 (?), 12:47 , 01-Окт-21, (97) +1 Чем PostgresQL 14 0 лучше Firebird 4 0 , iZEN (ok), 19:11 , 01-Окт-21, (122) –3 // Версия больше Ну але гараж, что за вопросы странные Чем гугл лучше яндекса и, Alladin (?), 20:06 , 01-Окт-21, (123) // Не лучше а хуже И ответ на этот вопрос вы узнаете сразу же как американский се, ыы (?), 19:58 , 02-Окт-21, (145) // Вы хотели сказать российский С чего бы американцам отключаться от Интернета , Прохожий (??), 05:55 , 03-Окт-21, (153) Есть такой список, страны угрожающие американскому образу жизни Это часть док, ыы (?), 10:21 , 03-Окт-21, (156) Пока из таких стран - Россия, Китай и КНДР, насколько мне известно Но, может, я, Прохожий (??), 20:32 , 05-Окт-21, (171) Наверное хорошая штука но ставить не буду никогда тк ее разрабы судя по документ, Док (?), 12:25 , 02-Окт-21, (140) // Очень странный довод По мне, так у них просто замечательно вылизанная документа, Аноним (-), 13:35 , 02-Окт-21, (143) +2 // Довольно хреновая у них документация Архитектура, например, вообще нигде не опи, Прохожий (??), 05:58 , 03-Окт-21, (154) // Так исходный код же есть Мало , ыы (?), 10:37 , 03-Окт-21, (157) +1 а когда уже нормальный active active кластер завезут , ыы (?), 19:42 , 02-Окт-21, (144) А когда уже direct io, undo нормальный завезут , Прохожий (??), 06:00 , 03-Окт-21, (155) 1,2,4,9,10,13,15,29,33,35,37,38,39,55,70,75,82,97,122,140,144,155

Сообщения

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

1. "Релиз СУБД PostgreSQL 14"	+11 +/–
Сообщение от menangen (?), 30-Сен-21, 19:58
Пора переводить прод с мускула на постгрю!
Ответить | Правка | Наверх | Cообщить модератору

Часть нити удалена модератором

	8. "Релиз СУБД PostgreSQL 14"	+4 +/–
	Сообщение от кукурузка (?), 30-Сен-21, 20:40
	> Если ваш "прот" можно вот так взять и перевести с MySQL на PostgreSQL, то это вызывает подозрение, что ваш "прот" - это сонник. А у этот комеент вызывает подозрения что вы не вкурсе как писать переносимые и расширяемые приложения и завязываетесь всегда на специфичные фишки всего вокруг. И это вызывает сильные подозрения что созданное вами пригодно для использования.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Релиз СУБД PostgreSQL 14"	+11 +/–
	Сообщение от Аноним (16), 30-Сен-21, 21:33
	Хм, тут как спросишь, какую СУБД выбрать в проект, так сразу начинается - "смотря какие задачи". А сейчас вдруг оказывается, что не надо фишки под задачи подбирать, пишите "переносимые".
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от Аноним (25), 30-Сен-21, 22:17
	У товарища просто примитивный бэкенд и задачи. Соответственно там и отличий никаких нет. И нагрузка соответствующая. Конечно у всех БД свой SQL несовместимый SQL. Перевести базу данных очень сложно. Надо обмазываться тестами на SQL запросы и их производительностью. Такого, конечно, никто не делает.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от пох. (?), 30-Сен-21, 23:05
	Делают, почему же не делают.  Только делают там где понимают, нахрена ж страдать. Ну например мы тут перешли с оракла на... оракл, ага. 19й. Ну пару раз в опу дали... и немного пришлось отсо...ть с производительностью в некоторых узкоспециальных местах. Куды деваться, немодные версии снимают с поддержки.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (48), 01-Окт-21, 03:29
	У тебя похоже вообще задач нет, одни смузи на уме.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	45. "Релиз СУБД PostgreSQL 14"	–3 +/–
	Сообщение от Умпа (?), 01-Окт-21, 02:01
	>> "смотря какие задачи" Смотря КАКАЯ ЛИЦЕНЗИЯ!!! 300% местных далба обов пишет для собственной бабушки, по ходу. За иороженку. И, да! -- мой код работает _И_ под MySQL, _И_ под MS SQL, _И_ под Oracle. Окощько открыл мана в преференциях мана, указала мана база мана и мана окей нажимала. А постгресс -- МИТ. Поэтому он.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	84. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Steve Ballmer (?), 01-Окт-21, 11:51
	Там наверное select password from wp_users where username = 'vasya'
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Релиз СУБД PostgreSQL 14"	+10 +/–
	Сообщение от 2021 (?), 30-Сен-21, 22:05
	Мамкиным понторезам не лень 2k21 вместо 2021 набирать.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	26. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от Аноним (16), 30-Сен-21, 22:17
	Папкиным манторезам не лень 2021 вместо 2021 набирать.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	27. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (25), 30-Сен-21, 22:19
	Ну они сейчас достаточно быстрые. На прошлом проекте в базу никто практически ни лез. Там даже кастомных индексов за запросы не было. Производительности хватало. И для многих проектов хватает.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	61. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Счетовод (?), 01-Окт-21, 08:01
	2k21 == 2210 != 2021
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

Часть нити удалена модератором

	89. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Аноним (89), 01-Окт-21, 12:10
	А тебя не обламывает раскладку переключать ради забивания"k"? Ты тратишь впустую свое время и совершаешь лишнее движение. Всякое лишнее движение не нужно, так как порождает хаос и тратит еще больше твоего времени в итоге. Лучше бы это время на что-то более полезное потратил. А так из закономерностей и секунды складываются в минуты/часы/дни/годы. Подобрал бы лучше кокой-нить мэйлпайл да пилил годный проект для хомо мыл. Ах да, так коммерционализация такая себе. Да. Поэтому ты лучше буш тут кочевряжится с написанием дат смайликами сношающихся поней, но делом не займешься. Пячалька.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

Часть нити удалена модератором

	108. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от Аноним (108), 01-Окт-21, 16:36
	Дело не в твоём времени, а в том что твой текст выглядит плохо, неприятно читать.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от мимокро (?), 01-Окт-21, 20:21
	лавров.jpg
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	128. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (128), 02-Окт-21, 01:37
	2k во всём мире значит 2000. И это правильно! Двадцать с лишним лет назад умный человек создал оригинальное сокращение при описании проблемы двухтысячного года. (Ну и плюс Windows 2k). Оно экономит целых 2 (два!) символа при написании и является совершенно правильным. Третье  десятилетие это сокращение не даёт покоя пытливым и ищущим умам. 2k3, 2k8 от этих новаторов ещё можно как-то объяснить - экономия целого символа, плевать, что с потерей смысла. Но 2к21 ничего не экономит, т.е. смысла не имеет, кроме оригинальничанья, кривляния, тролинга. Это примерно как 2км8 или 2кг5 - вот сколько это в позиционной системе счисления? А то, что в автозамену поставил - молодец, целеустремлённый. И немного напоминает то, что в последнее время веб-макаки делают с программированием и с языками в частности.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	131. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от ptr128 (?), 02-Окт-21, 07:23
	Сопротивление среднего резистора 2002 Ом или все же 2200 Ом? https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRtqmzN... А у этого резистора сопротивление, по Вашему, 33 Ом. Или все же 330? https://sesaga.ru/wp-content/uploads/2012/05/rasshifrovka.jpg Разделитель "K" нужно употреблять все же понимая, что он обозначает, а не от балды. 2021 = 2K021, а 2K21 = 2210
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	28. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от kai3341 (ok), 30-Сен-21, 22:33
	> завязываетесь всегда на специфичные фишки всего вокруг Падаван явно мал и глуп У разных реализаций разный синтаксис. То, что в Oracle зовётся decode, в sap hana именуется map. Разный синтаксис преобразования типов, и так далее. Так вот, всё это мелочи, полностью нивелируемые ORM. Дальше чуть поинтереснее. Есть сущность sequence -- простейший счётчик. Так вот, в sqlite секвенсов нет и судя по тому, как автор др*чит на автоинкременты, в ближайшей перспективе не появится. В Машу и Мускуль секвенсы завезли "на днях" -- наконец-то как у взрослых дядей сделали. Дальше ещё прикольнее. Оказывается, что разные реализации по-разному реализуют MVCC. Постгря гадит под ноги, что потом героически вычищает autovacuum. InnoDB, как и Oracle, имеет rollback и redo сегменты, и в обоих применяется кластерный индекс. Эти различия приводят к различным стоимостям операций CRUD. Например, rollback в postgres практически бесплатный, но заставит вас страдать в InnoDB и Oracle. Update в постгресе всегда создаёт новую строку в таблице, и частые обновления заставят вас страдать. Кластерный индекс позволяет найти запись за O(1) (ну почти, там есть нюансы) , что особенно прикольно на большом числе JOIN. Всё это заставляет реализовывать логику приложения по-разному. Расскажешь, как нивелировать эти различия?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	31. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от kissmyass (?), 30-Сен-21, 22:48
	вместо счетчика использовать свой генератор айдишек базирующийся на времени (или рандомный типа GUID, если первичный ключ может быть не кластерным, так называемый Heap, привет SQL Server), про многоуровневые JOINы забудь, особенно в нагруженных СУБД или при шардинге (да и не нужны они вообще, разве что для пейджинга с сортировкой на стороне СУБД), кластерный индекс и некластерный имеют всегда O(n), зависит от размера таблицы и балансировки дерева, разница между ними только в том, что кластерный определяет физическое размещение данных на диске, т.е. некластерному надо прочитать индекс, а потом саму запись, данные не находятся вместе с индексом, но один хрен это все O(n) и да абстрагироваться от деталей реализации замечательно помогают вьюхи и хранимые процедуры
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от kai3341 (ok), 30-Сен-21, 23:28
	> вместо счетчика ... GUID Очень умная идея. Привет, фрагментация кластерного индекса и всей таблицы, развлекуха с пагинацией и прочие весёлости > про многоуровневые JOINы забудь, особенно в нагруженных СУБД Прикольно. А что взамен? Через N+1 делать? > кластерный индекс и некластерный имеют всегда O(n) Прикольно. O(n) -- это table full access, то есть полное сканирование таблицы, игнорируя индекс > разница между ними только в том, что кластерный определяет физическое размещение данных на диске, т.е. некластерному надо прочитать индекс > данные не находятся вместе с индексом, но один хрен это все O(n) Подумай ещё раз, это не больно. Ты назвал взаимоисключающие вещи > и да абстрагироваться от деталей реализации замечательно помогают вьюхи и хранимые процедуры Как вьюха или хранимая процедура решает проблему неизбежного создания новой записи при операции UPDATE в постгресе? Как вьюха или хранимая процедура позволяют обойти проблему дорогого ROLLBACK в InnoDB или Oracle?
	Ответить | Правка | Наверх | Cообщить модератору

	41. Скрыто модератором	+2 +/–
	Сообщение от kissmyass (?), 01-Окт-21, 00:44
	вот не надо из контекста выдергивать, я дословно написал: "или рандомный типа GUID, ЕСЛИ первичный ключ может быть НЕ КЛАСТЕРНЫМ", если у тебя гуид в heap, каждая новая запись кладется в конец, а первичный ключ, который не кластерный сортируется как любой другой индекс > Прикольно. O(n) -- это table full access, то есть полное сканирование таблицы, игнорируя индекс O(n) это означает время зависящее от количества элементов в таблице, я имел ввиду что оно не константно как ты утверждал - т.е не O(1), но если быть уж совсем точным, то нужно брать асимптотическую сложность поиска в индексе, и если(!) это balanced tree, то O(log n)) > Подумай ещё раз, это не больно. Ты назвал взаимоисключающие вещи что там взаимоисклющающего? кластерный индекс хранится вместе со строкой и задает порядок физического следования строк в таблице (поэтому он и должен быть последовательным во избежании проблем с перфомансом), а если индекс не кластерный, то он не хранится с данными и никак не определяет порядок следования строк в самой таблице не кластерному индексу нужно прочитать свои данные на диске, и только потом по полученному указателю надо найти физическое расположение данных, это всего лишь плюс 1 дисковая операция, но асимптотическая сложность для обоих индексов будет одинакова, именно поэтому она и называется асимптотической. если тебе надо еще подробнее, то это не ко мне, я считаю, что я уже и так с тобой задержался... и вообще хочется спросить ты по жизни клоун? кому нужен твой пафос и высосанный из среднего пальца "покровительственный" тон!? очнись парень, ты обосpался...
	Ответить | Правка | Наверх | Cообщить модератору

	46. Скрыто модератором	–2 +/–
	Сообщение от kai3341 (ok), 01-Окт-21, 03:19
	> "или рандомный типа GUID, ЕСЛИ первичный ключ может быть НЕ КЛАСТЕРНЫМ", А, ну это точно решает проблему с пагинацией (нет) > если у тебя гуид в heap, каждая новая запись кладется в конец, а первичный ключ, который не кластерный сортируется как любой другой индекс Как это решает проблему фрагментации самого индекса? > O(n) это означает время зависящее от количества элементов в таблице, я имел ввиду что оно не константно как ты утверждал - т.е не O(1), но если быть уж совсем точным, то нужно брать асимптотическую сложность поиска в индексе, и если(!) это balanced tree, то O(log n)) Или используй О-нотацию правильно, или не используй вообще. "Ой ладно придираться, не O(N), а O(log N)" Разница между 4294967296 и 32 не имеет значения? > кластерный индекс хранится вместе со строкой Кластерный индекс нигде не "хранится". Его нет! Есть только адресное пространство диска, где запись размещается исходя из значения первичного ключа. Если строка занимает 123 байта, а значение первичного ключа 42, то расположение записи вычисляется элементарно, и к самой записи мы переходим за O(1) > и вообще хочется спросить ты по жизни клоун? кому нужен твой пафос и высосанный из среднего пальца > "покровительственный" тон!? очнись парень, ты обосpался... То есть по БД больше нечего сказать?
	Ответить | Правка | Наверх | Cообщить модератору

	56. Скрыто модератором	+2 +/–
	Сообщение от aa (?), 01-Окт-21, 07:03
	> А, ну это точно решает проблему с пагинацией (нет) а вы пагинацию делаете по первичному ключу? пользователь обычно хочет сортировку по чему-то более полезному, названию например, или цене. Зачем вобще первичный ключ при пагинации юзать?
	Ответить | Правка | Наверх | Cообщить модератору

	59. Скрыто модератором	+2 +/–
	Сообщение от Bx (ok), 01-Окт-21, 07:16
	> Кластерный индекс нигде не "хранится". Его нет! Есть только адресное пространство диска, где запись размещается исходя из значения первичного ключа. Если строка занимает 123 байта, а значение первичного ключа 42, то расположение записи вычисляется элементарно, и к самой записи мы переходим за O(1) Ого, а можно поподробнее? Про нигде не хранится. И как с nullable, delete и прочей малозначимой херней типа сжатия быть?
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	130. Скрыто модератором	+/–
	Сообщение от edo (ok), 02-Окт-21, 06:21
	> Если строка занимает > 123 байта, а значение первичного ключа 42, то расположение записи вычисляется > элементарно, и к самой записи мы переходим за O(1) И как оно вычисляется? Значение первичного ключа не равно номеру строки (и вообще может не быть числом).
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	49. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Аноним (48), 01-Окт-21, 03:32
	Обсмеялсо!
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	167. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Наме (?), 04-Окт-21, 10:20
	Мягко скажем, винегрет.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	40. "Релиз СУБД PostgreSQL 14"	–4 +/–
	Сообщение от Аноним (40), 01-Окт-21, 00:09
	Все нормальные люди используют orm а не пишут sql запросы и кот полностью переносимый А потом оно начинает тормозить и пишут запросы которые выполняться быстро но...
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	68. "Релиз СУБД PostgreSQL 14"	+3 +/–
	Сообщение от Аноним (68), 01-Окт-21, 08:59
	Все нормальные люди используют комбинацию подходов: используют ORM и Query Builders для банальных запросов, и пишут SQL там, где это требуется из соображений производительности. Универсальные ORM/QB хороши для рутинных вещей, но не способны сгенерировать оптимальные запросы и использовать специфику конкретной РСУБД.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Релиз СУБД PostgreSQL 14"	–2 +/–
	Сообщение от kai3341 (ok), 01-Окт-21, 12:21
	> и пишут SQL там, где это требуется из соображений производительности Открой для себя SQLAlchemy. Эта ORM позволяет извлечь как все преимущества императивного подхода, разбив ORM-запрос на модули и вынеся подзапросы отдельно, так при этом сохранить все преимущества SQL -- ты волен написать любой валидный запрос (почти. Не без косяков. Но они устранимы)
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Наме (?), 01-Окт-21, 12:29
	А как там rollbacks-ы отрабатывают? Вот налепил ты объектов, решил их транзакционно поменять, поменял и тут -- хлоп -- в самом конце какое-то исключение вылезло. Как твоя Алхимия такую ситуацию обрабатывает? Состояние объектов откатит, как было до начала транзакции? А?
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от kai3341 (ok), 01-Окт-21, 18:10
	Отрабатывает. Только я избегаю использовать ActiveRecord
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (68), 02-Окт-21, 10:20
	Не надо лепить объекты по принципу ActiveRecord для проектов сложнее бложика с комментариями. Надо использовать Data Mapper и принцип Aggregate Root из DDD. А роллбэки там даже распределенные есть, там отличный transaction manager.
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	104. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от 3 (?), 01-Окт-21, 14:20
	внезапно, мир не ограничен петоном. и даже в мире питона этих орм штук 10, например джанговское, peewee и тд. из чего следует, что алхимия не универсально-могуча.
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	120. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от kai3341 (ok), 01-Окт-21, 18:13
	Количество != качество. С джангой сравнил. Сравнил бы в knex -- был бы другой разговор
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (108), 01-Окт-21, 16:40
	SQLAlchemy прекрасный ORM, один из лучших среди всех языков. Но даже на нём написать запрос на пару экранов это будет мучение.
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	119. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от kai3341 (ok), 01-Окт-21, 18:11
	Писал запросы на пару экранов. Не испытал мучения, а наоборот, писал с удовольствием. Как я сказал ранее, алхимия позволяет получить все преимущества императивного подхода (модульность, переиспользование кода и интроспекцию), не потеряв при этом преимуществ сырого SQL
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (68), 02-Окт-21, 10:18
	SQLAlchemy прекрасна. Но ее прекрасность обусловлена особенностями Питона, на другом языке такую же красоту не сделать. Можно попробовать изобразить что-то подобное на Kotlin с его DSL, но вряд ли у меня дойдут руки :(
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	94. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Наме (?), 01-Окт-21, 12:30
	Сейчас, в общем-то, не важно как составлен запрос, если он логически корректен. С ОРМами другие проблемы.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	121. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от kai3341 (ok), 01-Окт-21, 18:18
	Как раз важно. Есть 100500 способов составить запрос, получив на выходе один и тот же набор данных, но с различными стратегиями вычитывания данных. Производительность может различаться в разы. Например, SQL позволяет поместить подзапрос не только в `FROM`, но и в `SELECT`. Стратегия извлечения данных будет сильно разной
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от Прохожий (??), 03-Окт-21, 05:12
	Стратегия извлечения в нормальной СУБД будет зависеть от оптимизатора запросов, а не от того, как запрос написан.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от kai3341 (ok), 03-Окт-21, 15:53
	> Стратегия извлечения в нормальной СУБД будет зависеть от оптимизатора запросов, а не от того, как запрос написан. Святая наивность. Не похоже, что вы хоть раз писали SQL запросы сложнее `SELECT * FROM ${TABLE}`. Главный оптимизатор запроса находится перед компом. Оптимизатор БД же тупенький конечный автомат, способный только предварительно вычислить константы, определить мощность множества (cardinality) и выбрать подходящий индекс (или неиспользование индекса -- бывает, так выгоднее).
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Прохожий (??), 05-Окт-21, 20:29
	> Не похоже, что вы хоть раз писали SQL запросы сложнее `SELECT * FROM ${TABLE}`.> Это вы мне говорите, человеку с 20-летним стажем работы с СУБД? Да, изначально оптимизаторы были тупенькие и простенькие. Да, иной раз до сих пор промахиваются (редко, если говорить об Oracle, например). Но вот Postgres SQL содержит уже что-то машинно обученное (вряд ли это может приравнять к тупенькому конечному автомату). Oracle в подавляющем большинстве случаев прекрасно справляется с многостраничными SELECT-ами. А тенденция такова, что оптимизаторы будут всё более и более совершенными. И не такие уж они простенькие и тупенькие на сегодняшний день, как вы тут рассказываете - некоторые запросы вполне могут быть переписаны автоматически для более оптимального выполнения.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от kai3341 (ok), 05-Окт-21, 21:56
	>> Не похоже, что вы хоть раз писали SQL запросы сложнее `SELECT * FROM ${TABLE}`.> > Это вы мне говорите, человеку с 20-летним стажем работы с СУБД? FYI: стаж != экспертиза > Да, изначально оптимизаторы были тупенькие и простенькие. Да, иной раз до сих пор промахиваются (редко, если говорить об Oracle, например). Как бы да. Когда сам знаешь, где разбросаны грабли, ты их обходишь. Как я говорил, основной оптимизатор SQL-запроса этот запрос пишет. А оптимизаторы ошибаются. И иногда не просто ошибаются, а даже обсираются. Оптимизаторы очень не любят большое число JOIN на одном уровне -- Oracle не шмог в похожет случае. Кстати, основная причина промаха оптимизатора -- некорректная оценка мощности множества. > Но вот Postgres SQL содержит уже что-то машинно обученное (вряд ли это может приравнять к тупенькому конечному автомату). Вот отсюда подробнее. Где они там машинное обучение всунули, и, главное, зачем. Предоставьте пруфы. > Oracle в подавляющем большинстве случаев прекрасно справляется с многостраничными SELECT-ами. Ну вообще да, в 99% случаев они неплохо справляются, если самому на грабли не наступать. > А тенденция такова, что оптимизаторы будут всё более и более совершенными. И не такие уж они простенькие и тупенькие на сегодняшний день, как вы тут рассказываете - некоторые запросы вполне могут быть переписаны автоматически для более оптимального выполнения. Я не говорю о том, что оптимизатор не может вообще ничего. И я согласен, оптимизаторы становятся всё умнее (или менее глупыми. Была ржака как-то -- в оптимизаторе MySQL нашли место, где rvalue не вычислялся на момент анализа запроса, хотя все данные для этого были). Оптимизаторы действительно творят невозможное. Помнится, запрос по временному ряду был очень весело ограничен: `WHERE TRUNC(event_created, 'MM') = :event_month` -- так вот, оптимизатор тут таки шмог, и вместо ожидаемого TABLE FULL ACCESS внезапно был INDEX RANGE SCAN. Да, он вычитал занные за весь год, но это сильно лучше полного чтения таблицы. Но ещё раз -- оптимизатор -- это программа, она не может ничего "выдумать". Задача оптимизатора -- сократить число чтений. Принятие же решения по сути является задачей поиска минимума. Он способен перебрать ограниченное число вариантов -- не больше, чем в него заложил программист. Оптимизатор, каким бы "умным" он ни был, останется тупеньким конечным автоматом. И очень странно, что я об этом рассказываю человеку, у которого "20 лет стажа работы с СУБД"
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от mos87 (ok), 01-Окт-21, 07:58
	если ты думаешь, что в риал ворлде (с)(тм) кто-то настолько заморачивается, что в одном проекте пишет скуль запросы сразу под разные ДБ (хотя всегда сидят на 1й одновременно), то ты либо 1) не знаешь о чем говоришь 2) не работаешь с запросами сложнее SELECT a_couple_of_columns FROM one_single_table
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	150. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Прохожий (??), 03-Окт-21, 05:17
	Возьмём, например, 1С. Несколько мне известно, их продукт работает в реальном мире под разными СУБД, и там запросы сложнее, чем вы написали. Я работаю в компании, которая разрабатывает продукты (сложные и большие) под разные СУБД.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от mos87 (ok), 03-Окт-21, 10:51
	Насколько мне известно там постгрес. но вполне может статься что бывает и разное. скорее всего может. только в одной конторе для одного проекта никто не будет расписывать запросы с учетом разницы между СУБД такой запрос выглядит сложным: SELECT col1||col2 FROM table ? вроде нет. Однако он может давать совершенно разные результаты на Oracle и сабже, а на других вовсе вызовет ошибку синтаксиса. ты вот сейчас серьёзно сказал, что люди для себя для своих проектов (или для клиентов, там обычно *всё равно подразумевается что СУБД известна и незаменяема*) сидя на одной СУБД будут писать этот запрос так: SELECT НЕКАКАЯ_ФУНКЦИЯ_ОПРЕДЕЛЯЮЩАЯ_ВЫПОЛНЯЮЩУЮ_СУБД( есди_оракл то col1||col2, если_пг COALESCE( col1, 0 )||COALESCE( col2, '0' ), если_мускль CONCANT( col1, col2 ), если_голимый col1+col2 ) FROM table
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Прохожий (??), 05-Окт-21, 20:20
	Смотреть в сторону ORB.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от mos87 (ok), 05-Окт-21, 20:32
	зачем? (и что это?)
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Прохожий (??), 05-Окт-21, 20:37
	Object Relational Bridge. Зачем смотреть? Есть у вас сложный продукт, который однако, легко разбиваются на модули. Можете целиком продавать все модули (крупным денежным клиентам) вместе с Oracle. А можете отдельные модульки с PostgreSQL мелким небогатым. В итоге у вас более полный охват рынка.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Релиз СУБД PostgreSQL 14"	+2 +/–
	Сообщение от letsmac (ok), 01-Окт-21, 09:45
	Ну если у тебя SQL это тупой Store без хранимых процедур и ты слово профайлер слышишь в первый раз - то тогда да, это не проблема. Купи побольше процов в облаке и всё работать будет.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	77. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Наме (?), 01-Окт-21, 11:10
	Это ваше "переносимое и расширяемое", если ему пофиг на транзакционное ядро, которое под ним лежит, скорее всего никакие СУБД вообще не использует. ИСАМ и реляционные БД с полноценным WAL-ом и MVCC это абсолютно разные вселенные. Если ИСАМ был выбран осознанно, то переводить его на реляционные схемы c MVCC нет никакого смысла -- будет просто тупо медленней и в разы более толсто.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	135. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от ptr128 (?), 02-Окт-21, 07:49
	> завязываетесь всегда на специфичные фишки А варианты? Хотите приведу целый ряд запросов, которые вообще без изменений легко выполняются и в MS SQL и в PostgreSQL, но во втором без модификации уходят в глухой table scan? Обзор тут: https://www.endpoint.com/blog/2020/06/postgresql-improve-gro.../ Я уже молчу о временных и, тем более, глобальных временных таблицах. Тут уже в каждой СУБД свои заморочки, требующие при миграции, нередко, просто переписывания кода.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	34. "Релиз СУБД PostgreSQL 14"	+5 +/–
	Сообщение от й (?), 30-Сен-21, 23:17
	нооо мооой прооот! свитый из багов и снов всем моим бедам назло вовсе не так уж плох
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Релиз СУБД PostgreSQL 14"	–1 +/–
	Сообщение от Док (?), 02-Окт-21, 12:19
	Оо подошли старперские оптимизации бесконтактного боя
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Релиз СУБД PostgreSQL 14"	–1 +/–
	Сообщение от kissmyass (?), 30-Сен-21, 21:49
	зачем?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	47. "Релиз СУБД PostgreSQL 14"	+/–
	Сообщение от Аноним (48), 01-Окт-21, 03:27
	Пора тебе побеспокоиться за свой тыл.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	125. "Релиз СУБД PostgreSQL 14"	+1 +/–
	Сообщение от FSA (??), 01-Окт-21, 20:43
	> Пора переводить прод с мускула на постгрю! Не стоит. Но стоит задуматься о создании нового прода уже на PostgreSQL. Я не особый спец. Любитель. Но приятно было отказаться от MySQL. Сначала привыкаешь к особенностям. Потом учишься делать хитрые запросы. Потом балуешься с json, которые участвуют в индексах. Потом понимаешь, что для того, чтобы сделать то, что позволяет PostgreSQL на MySQL, мягко говоря, сложно. Но если ты просто меняешь БД в настройках своей CMS - то это не миграция, а херня. Не стоит. Твой код должен быть написан именно для PostgreSQL с учётом его особенностей. Код не может быть заточен и под MySQL и PostgreSQL. Это компромисс для эникейщиков, чтобы поставить систему на любой сервер.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

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

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