Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (1)

Наибольший вклад в теги

Все теги (7)

Лучшие ответы пользователя

Все ответы (3)
  • Как поступают фрилансеры с серверной частью в малых проектах?

    @orbit070
    Я не фрилансер, но делал бы так:

    1. Если сервер не нужен - вопрос решен
    2. Если сервер нужен и его делает третья сторона - вопрос решен
    3. Если сервер нужен и его делать самому, то:

    а) анализ функционала приложения. Если это условно говоря какие-нибудь заметки или список рецептов с сохранением на сервере для надежности, то сообщать клиенту о том, что существует сервер и для чего он нужен смысла нет. Берется бесплатный тариф firebase и готово. Можно даже держать один общий аккаунт для таких "несущественных" серверов.

    б) если приложение потенциально может обрасти большим количеством данных, то объясняем клиенту, что к чему. Что данные где-то надо хранить, и это где-то называется сервер. Что на первых порах можно использовать бесплатное решение(тот же firebase), но если данных станет больше то придется переходить на платный тариф. Предлагать два варианта: либо он сам заводит этот сервер и оплачивает, либо предлагаю самому этим заниматься за стоимость сервера + дополнительные пару копеек.
    Ответ написан
  • Какая оптимальная структура для таблицы "лайков"?

    @orbit070
    Если, чисто теоретически представить, что пользователей миллионы, а постов десятки миллионов, является ли такая структура оптимальной?

    Почти. Нужно применить дублирование и прокинуть в эту таблицу сразу все те поля, которые вам могут пригодиться для отображения, иначе каждый раз придется делать join, чего бы не хотелось при highload. То есть нужно добавить в таблицу сразу поля вроде user_name, post_title, post_body, и т.д(в общем все то, что вы планировали доставать с помощью join).

    На счет "пользователей миллионы, а постов десятки миллионов":
    Если у вас будет такое количество данных, то вам в любом случае в какой-то момент придется прибегнуть к горизонтальному шардингу, поэтому если считаете что проект реально может дорасти до такого количества данных лучше сразу учесть это и спроектировать базу данных так, чтобы горизонтальный шардинг не стал проблемой.

    нужно ли тут поле id, или PK сделать составной (post_id, user_id) или PK вообще не нужен? Это влияет на селект?


    Зависит от сценариев использования(подумайте, в каком случае вам нужно будет поле id), но в большинстве случаев оно не нужно и такие поля вводят для душевного спокойствия и гармонии. На селект это не влияет, ведь все равно вы будете делать выборку либо по user_id либо по post_id(опять же, это в большинстве распространенных сценариев, если у вас есть какая-то логика, где нужно будет выбирать из таблицы likes записи по какому-то намеренно введенному идентификтаору, то вводите).
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (5)