У вас с автором разный опыт. У вас 1800 сущностей с FK на 1 RPS. У автора шардированные кластера с микросервисами где нормальные FK просто не поддерживаются и не имеют смысла.
Эмм, нет. Вы делите на черное и белое. Или реляционная СУБД или нет, выбирай. А мне могут нравиться транзакции, но не нравится FK. Естественно я выберу реляционную СУБД, но использовать FK не буду.
"В таблице дат внешний ключ - id статей. Такая структура БД нужна, чтобы..." - FK никак не влияет на функциональность. "создавать виды для просмотра дат изменений конкретной(ых) статьи(ей)" - как обычно SQL-запросом, FK тут не причем
"Правильная база для правильной задачи. MongoDB: Для оперативных, часто меняющихся данных: хранение статусов задач, их параметров и JSON-результатов."
Будь честным. Просто напиши, что хотел поиграться с Монгой. Прикалывают люди, которые пытаются оправдать выбор технологии придуманными аргументами.
Помню коллега на работе хотел позаниматься resume development и затянуть в любой проект GraphQL. Он был падок на что-то новенькое и приводил нереальные, нелогичные и нерациональные аргументы. Но я был непреклонен)
Расскажу свою историю. В детстве занимался занимался шахматами, на турики гонял. В течение дня захожу пару раз на lichess инкогнито. 5 лет назад было очень просто. 90% партий - соперник не очень играет, я быстро выигрываю и говорю себе "Всё ещё достоин". Но после выхода фильма "Ход королевы" в 2020 всё кардинально изменилось. Все стали профессиональными профессионалами, всё видят, играют быстро и точно, короче читеры везде.
Год назад заметил другую особенность. Я играю 2+1 (2 минуты в начале, +1 секунда добавления на ход) и 80% партий заканчивается так: на 50-60 ходу я проигрываю по времени. И что тут такого? Дело в том, что 50-60 ходов это много, то есть игроки примерно равны и исход решается на секундах в самом конце. То есть мой соперник не читер, но и не любитель, а моего уровня. Как это возможно, если я захожу инкогнито?
Я думаю так. Нейронка в начале делает стандартные дебютные ходы и по моим ходам понимает мой уровень игры. А потом начинает играть в силу этого уровня. А т.к. это нейронка, то человек проигрывает в конце по времени (хотя и не всегда). Если бы я админил шахматный сайт, то так бы и сделал) В таком варианте не получается скучных однокалиточных игр, а какая-то жизнь в партии. Ток сделал бы ослабевание ближе к концу, чтобы happy end был почаще)
Наблюдая за развитием популярных проектов можно увидеть как меняется ответ на вопрос "А зачем использовать этот проект?". Давайте посмотрим как менялся этот ответ для проекта Next с течением времени, 1 -> 2 -> 3. 1. SEO - обычные SPA не индексируются, го просто добавим SSR без необходимости переписывания нашего SPA-приложения. 2. Performance - делая SSR мы избавляемся от водопада запросов и уменьшаем клиентский рендеринг. 3. Политика - Next слился с React, экосистема хочет замкнуться на Vercel, cкупаюся конкуренты (Nuxt и Svelte), релизы хотят решить проблемы Vercel, а не твои, хочется бежать. (мы находимся здесь)
А теперь посмотрим на какой стадии находится Bun. 1. Performance - нууу нет. Кажется с самого начала слова "fast" и "Bun" слились вместе. Но когда мы говорим fast хочется x10, x5, ну хотя бы x2. Но таким цифрам просто неоткуда взяться (я говорю про runtime). На реальном проекте с реальной бизнес логикой скорость на Bun будет ~ x1.3 по сравнению с Node. А вот время старта сильно лучше в Bun за счет движка JavaScriptCore. 2. Экосистема - ДА и очень ДА. Unix-way подход в JS экосистеме был ошибкой. Шутки про пакеты is-odd, is-even и когда наше приложение представляет собой пакет с пакетиками - это совсем не шутки. Я просто устал от этого. Посмотрел сейчас историю файла package.json, кол-во зависимостей после переезда на Bun сократилось в 2.5 раза. И как пишет сам Bun "Время, которое вы тратите на поиск библиотек, можно было бы потратить на разработку приложения." 3. ??? - а вот здесь вопросы, как и на чем будет зарабатывать Bun и какие риски это принесет. Не хочется, чтобы случилось как с Next. Я думал именно в этом релизе мы узнаем ответ, но кажется ещё рано.
Итого: я перевел на Bun все свои Node проекты - и backend, и frontend приложения, стало легче дышать. Т.к. это drop in replacement для Node я не вижу особо рисков в данный момент, а может и в будущем.
Когда ты берешь что-то в кавычки, это обозначает цитату. Но такой цитаты в статье нет. Кто кого хочет обмануть?
У вас с автором разный опыт. У вас 1800 сущностей с FK на 1 RPS. У автора шардированные кластера с микросервисами где нормальные FK просто не поддерживаются и не имеют смысла.
Можно сделать одним SQL-запросом и проблем не будет, учите SQL
Это статья из твоей фантазии. Возвращайся к реальности
Эмм, нет. Вы делите на черное и белое. Или реляционная СУБД или нет, выбирай. А мне могут нравиться транзакции, но не нравится FK. Естественно я выберу реляционную СУБД, но использовать FK не буду.
Не фантазируй, а перечитай статью
Не фантазируй, про PK ничего не было
"В таблице дат внешний ключ - id статей. Такая структура БД нужна, чтобы..." - FK никак не влияет на функциональность.
"создавать виды для просмотра дат изменений конкретной(ых) статьи(ей)" - как обычно SQL-запросом, FK тут не причем
Jwt токены это получение юзера, а не валидация. То что юзер не удален и не забанен и тд и тп только с Jwt не проверить
Обман. По FK вы проверите только существование, вы не проверите "такой shop может принимать заказы, что в нем есть указанные товары" и тд и тп
Нет FK - нет проблем
"Правильная база для правильной задачи. MongoDB: Для оперативных, часто меняющихся данных: хранение статусов задач, их параметров и JSON-результатов."
Будь честным. Просто напиши, что хотел поиграться с Монгой. Прикалывают люди, которые пытаются оправдать выбор технологии придуманными аргументами.
Помню коллега на работе хотел позаниматься resume development и затянуть в любой проект GraphQL. Он был падок на что-то новенькое и приводил нереальные, нелогичные и нерациональные аргументы. Но я был непреклонен)
Ребят, мой сервис держит 31 536 000 запросов в год (1 RPS)
Расскажу свою историю. В детстве занимался занимался шахматами, на турики гонял. В течение дня захожу пару раз на lichess инкогнито. 5 лет назад было очень просто. 90% партий - соперник не очень играет, я быстро выигрываю и говорю себе "Всё ещё достоин". Но после выхода фильма "Ход королевы" в 2020 всё кардинально изменилось. Все стали профессиональными профессионалами, всё видят, играют быстро и точно, короче читеры везде.
Год назад заметил другую особенность. Я играю 2+1 (2 минуты в начале, +1 секунда добавления на ход) и 80% партий заканчивается так: на 50-60 ходу я проигрываю по времени. И что тут такого? Дело в том, что 50-60 ходов это много, то есть игроки примерно равны и исход решается на секундах в самом конце. То есть мой соперник не читер, но и не любитель, а моего уровня. Как это возможно, если я захожу инкогнито?
Я думаю так. Нейронка в начале делает стандартные дебютные ходы и по моим ходам понимает мой уровень игры. А потом начинает играть в силу этого уровня. А т.к. это нейронка, то человек проигрывает в конце по времени (хотя и не всегда). Если бы я админил шахматный сайт, то так бы и сделал) В таком варианте не получается скучных однокалиточных игр, а какая-то жизнь в партии. Ток сделал бы ослабевание ближе к концу, чтобы happy end был почаще)
С детства за Bun.
Наблюдая за развитием популярных проектов можно увидеть как меняется ответ на вопрос "А зачем использовать этот проект?". Давайте посмотрим как менялся этот ответ для проекта Next с течением времени, 1 -> 2 -> 3.
1. SEO - обычные SPA не индексируются, го просто добавим SSR без необходимости переписывания нашего SPA-приложения.
2. Performance - делая SSR мы избавляемся от водопада запросов и уменьшаем клиентский рендеринг.
3. Политика - Next слился с React, экосистема хочет замкнуться на Vercel, cкупаюся конкуренты (Nuxt и Svelte), релизы хотят решить проблемы Vercel, а не твои, хочется бежать. (мы находимся здесь)
А теперь посмотрим на какой стадии находится Bun.
1. Performance - нууу нет. Кажется с самого начала слова "fast" и "Bun" слились вместе. Но когда мы говорим fast хочется x10, x5, ну хотя бы x2. Но таким цифрам просто неоткуда взяться (я говорю про runtime). На реальном проекте с реальной бизнес логикой скорость на Bun будет ~ x1.3 по сравнению с Node. А вот время старта сильно лучше в Bun за счет движка JavaScriptCore.
2. Экосистема - ДА и очень ДА. Unix-way подход в JS экосистеме был ошибкой. Шутки про пакеты is-odd, is-even и когда наше приложение представляет собой пакет с пакетиками - это совсем не шутки. Я просто устал от этого. Посмотрел сейчас историю файла package.json, кол-во зависимостей после переезда на Bun сократилось в 2.5 раза. И как пишет сам Bun "Время, которое вы тратите на поиск библиотек, можно было бы потратить на разработку приложения."
3. ??? - а вот здесь вопросы, как и на чем будет зарабатывать Bun и какие риски это принесет. Не хочется, чтобы случилось как с Next. Я думал именно в этом релизе мы узнаем ответ, но кажется ещё рано.
Итого: я перевел на Bun все свои Node проекты - и backend, и frontend приложения, стало легче дышать. Т.к. это drop in replacement для Node я не вижу особо рисков в данный момент, а может и в будущем.
Согласен, современные детсады и школы это про дрессировку и послушание в первую очередь. Это основная цель, а не какие-то там знания.
Я никого не хотел убивать. Со мной что-то не так?
Я напишу цикл на своем любимом языке программирования в котором буду делать http GET на твой проект. Отгадай как Cloudflare защитит тебя от этого?
Никак. Cloudflare подходит только для защиты от больших распределенных атак.