| |
| |
| 3.7, fyjybv (?), 15:08, 04/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
FoxPro, Paradox нету. Видел даже вакансию для разработчика FoxPro.
| | |
| |
| 4.57, 1 (??), 11:11, 07/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
А вакансий для разработчиков на коболе для IBM IMS нет ?
| | |
|
|
| 2.11, 223 (?), 16:45, 04/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Мария, которая DB, как и оригинальный мускуль не отличается эффективностью,недавно на пет-проекте начались дропы данных, мария тупо не успевала обновлять данные если параллельно на ноде шли бэкапы, добавляли индексы к таблицам еще какие-то оптимизации, бестолку, обьем данных по чуть-чуть тоже рос, ..переползли на на посгресс, проблемы исчезли, хотя конечно с посгрессом тоже пришлось потанцевать. Мария сильно проще это факт.
| | |
| |
| 3.15, Аноним (15), 17:16, 04/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
сначала выберут негодный инструмент, а потом свмотрят на свои яйца, не мешают ли
| | |
| |
| 4.18, FSA (??), 17:36, 04/04/2025 [^] [^^] [^^^] [ответить]
| +8 +/– |
 > сначала выберут негодный инструмент
Правильно. Сразу бы взяли PostgreSQL, проблем бы не знали
| | |
| |
| 5.36, tty2 (?), 22:11, 04/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
По моему опыту - бек не смог в транзакции. Ну а "дропами" назвали отвалы запросов по таймауту.
И да, лить данные во время бекапа на мастере тот ещё профессионализм.
Был бы постгресс - бюджет был на оборудование +50%…
| | |
| |
| 6.62, 223 (?), 11:16, 11/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Данные летели по udp 24/7, и было жестко прибито обрабатывать их в 2 потока, и дропы - это не обработка udp пакетов, ценности в даных большой нет - пет проект как есть.
| | |
|
| 5.63, 223 (?), 11:20, 11/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
>> сначала выберут негодный инструмент
> Правильно. Сразу бы взяли PostgreSQL, проблем бы не знали
Коллеги, а нечего тот факт что постгрес не умеет кластер без танцев с бубном, или хотябы пользователя добавить с правами удаленного подключения без танцев с конфигами и перезагрузками..
написать хреньку, которая умеет быстрее чтото одно и не умеет ничего другого проблемы нет и никогда не было, а постгрес не умеет из каробки много, да чего стоит невосприимчивость к регистру имен таблиц, госпосди, кто это виндузятничество придумал, 2025 год на дворе
| | |
|
|
| 3.47, Tron is Whistling (?), 09:48, 05/04/2025 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> параллельно на ноде шли бэкапы
Сначала сунут базу на тормозные HDD с минимальным пулом буферов, потом ещё добавят к этому всему бэкап, потом жалуются. Ещё и бэкап поди с блокировкой таблиц - естественно отвалы будут, --single-transaction не зря придумали, да и оно не всегда возможно.
1) Понять, сколько буфера надо для типа запросов и нагрузки
2) Убедиться, что дисковая система успевает данные отписывать
3) Не гонять бэкапы базы на нодах в прайм тайм, у MySQL есть вполне себе удобная репликация - пользуйтесь. Если нужна предсказуемость - сливайте данные на бэкапную ноду и бэкапьте оттуда.
| | |
|
| 2.44, Аноним (44), 03:17, 05/04/2025 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Лучше только SLite!
Эх, такие то теплые воспоминания, еще студенческой юности... Пхп 5...
| | |
|
| |
| |
| |
| 4.51, Аноним (51), 20:45, 05/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Для этого можно воспользоваться вордпрессовским комьюнити-плагином для работы с postgresql.
Очевидно, что сабж немножко не для этого.
| | |
|
|
|
| 1.9, BorichL (ok), 16:07, 04/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Ну как бы забавно. Ну наверно для работы с базой, где 10 тысяч ХеллоВордов в табличках просто лежит пригодится.
Но в остальном то если приложение написано под такую убогую СУБД как MySQL, то зачем ему прослойка под монструозный PostgreSQL, пусть так и долбится в этом примитиве... Чтобы поиметь плюсы от перехода с MySQL на PostgreSQL, то сохранить структуру таблиц базы наверно удастся (если она изначально была толковой), но всё остальное придётся переработать полностью.
| | |
| |
| 2.14, Аноним (13), 17:07, 04/04/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
Чтобы запустить какую-нибудь небольшую фигню, написанную для mysql, в среде, где есть большой и задорого обслуживаемый постгрес, а ни специалистов, ни желания возиться с mysql нет.
| | |
| 2.22, пох. (?), 19:21, 04/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Ну как бы забавно. Ну наверно для работы с базой, где 10 тысяч ХеллоВордов в табличках
> просто лежит пригодится.
такой базе и кривовраппер не нужен - просто драйвер с mysql на pdo-pgsql сменить.
(вроде в посгре даже ж научились имитировать mysql'евые автоинкременты, а не select from sequence?)
> то зачем ему прослойка под монструозный PostgreSQL
вот и я тоже не пойму, что там такого может быть что под постгрезом требует трансляции (и при этом еще и может быть странслировано, а не ой тут такой фигни просто не бывает)
Ну, видимо, пацаны чо-та знают.
| | |
| |
| 3.27, BorichL (ok), 19:39, 04/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
> вот и я тоже не пойму, что там такого может быть что
> под постгрезом требует трансляции (и при этом еще и может быть
> странслировано, а не ой тут такой фигни просто не бывает)
> Ну, видимо, пацаны чо-та знают.
Ну вот что с ходу нашёл, что может нередко использоваться:
MySQL Syntax:
SELECT column_name(s) FROM table_name ORDER BY column_name(s) WHERE condition LIMIT number;
Oracle 12 Syntax:
SELECT column_name(s) FROM table_name ORDER BY column_name(s) FETCH FIRST number ROWS ONLY;
Названия функций, работающих с датами, отличаются, ну вобщем совместимость как всегда так себе.
Но основная проблема таких прокси в том, что оптимизаторы запросов работают абсолютно по разному и транслированный запрос, "летающий" на исходном сервере, может тупить на другом.
| | |
| |
| 4.37, пох. (?), 22:27, 04/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
так то орацл.
Постгрез умеет в LIMIT Б-г ведает сколько лет (он еще и в OFFSET умеет)
Правда, есть некоторые сомнения как раз в плане того что оптимизатору это понравится, но тут транслятор вряд ли чем поможет.
| | |
|
|
|
| 1.10, Аноним (10), 16:28, 04/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Годнота, репозиторий моего дистрибутива GNU/Linux хранит информацию о пакетах в базе данных MySQL/MariaDB. Теперь желающие поиграться смогут испосльзовать СУБД PostgreSQL.
| | |
| 1.32, Аноним (32), 20:28, 04/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А есть инструмент для миграции с одной версии PostgreSQL на другую? Без дампов, подъёмов одновременно двух инстансов разных версий и прочих развлечений, не свойственных взрослым людям?
| | |
| |
| 2.38, пох. (?), 22:29, 04/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
> А есть инструмент для миграции с одной версии PostgreSQL на другую? Без
> дампов, подъёмов одновременно двух инстансов разных версий и прочих развлечений, не
> свойственных взрослым людям?
взрослым людям несвойственно на ходу мигрировать на аж другую ветку базы, не имея даже плана Б на случай если что-то пойдет не так.
| | |
| |
| 3.42, Аноним (32), 01:36, 05/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
План Б, конечно, есть. Вопрос в сложности реализации плана А.
Ну и отдельно вспомним про машины разработчиков, где план Б - это просто почистить базу и из миграций создать новую. Можно, конечно, сбрасывать базу при !каждом! обновлении, но mysql, с которого предлагается мигрировать в новости, позволяет жить проще.
| | |
| |
| 4.50, пох. (?), 15:30, 05/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> План Б, конечно, есть. Вопрос в сложности реализации плана А.
ну вот аналогичный план oracle 12 -> 19 занял у нас пол-года работы и примерно десяток дополнительных серверов. Полки ему тоже пришлось купить новые, но тут ладно, все равно было пора менять.
А простота - она хуже воровства. Хеловроту и mysql излишен, хватило бы и sqlite - там и вовсе мигрировать нечего.
| | |
| |
| 5.52, Аноним (52), 23:31, 05/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> ну вот аналогичный план oracle 12 -> 19 занял у нас пол-года работы и примерно десяток дополнительных серверов.
ну, теперь отмучались и больше такого не будет за отсутствием самого оракела. А то бы пришлось PL/SQL на JavaScript переписывать в 23ai
ПС. я сам кстати при переходе с 12 на 19 один воркароунд написал - при запросе с 19 простого оракла к 12.1 eхadate перестало работать распараллеливание через dbms_scheduller - я его сам реализовал с помощью dbms_parallel и отправил баг в Оракл, но так и не дождался его решения. причем случай был специфический на 5-7 случаев срабатывания бал один случай несрабатывания (разные источники, не один и тот же)
| | |
|
|
|
| |
| 3.41, Аноним (32), 01:33, 05/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Я правильно понял, что оно требует, чтобы обе версии postgresql были установлены одновременно: и старая, и обновлённая?
| | |
|
|
| 1.48, onanim (?), 11:30, 05/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> убогий MySQL
> монструозный PostgreSQl
посоветуйте хорошую БД, чтоб был крепкий середнячок между вышеуказанными двумя
| | |
| |
| 2.49, тоже Аноним (ok), 11:59, 05/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Мускуль - и есть крепкий середнячок между убогим Скулятом и монструозным Постгресом.
Его, как Пых, будут хоронить десятилетиями, но он продолжит работать на большинстве серверов. Вплоть до качественного изменения условий работы.
| | |
| |
| 3.60, Аноним (60), 17:45, 07/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Мускуль
>Скулятом
>Пых
Ну вы же не строитель, что вы из себя строите?
| | |
|
|
| 1.55, Аноним (55), 10:00, 07/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Я уж подумал openHalo)по аналогии с openMW) кто-то смог сварганить, а оно вот это вот - всё таблички да списки...
| | |
|
