EntityFrameworkCore 6 Столбец Status

Добрый день!

Не было раньше реального опыта на EntityFramework, есть несколько вопросов.

База данных MySQL в течение месяца разрастётся и будет содержать около 100млн строк в разных таблицах.

Во всех таблицах есть столбец `Status` который содержит что-то банальное типа ON|OFF|WAIT|и т.д.
Чтобы работать из кода, очень удобно использовать `Status` как enum
А в БД его хранить как int (0, 1 или 2).
Но по 4байта 100млн строк будут занимать 400MB.


Так же можно сделать отдельную таблицу `Status` на базе вышеприведённого enum.
И делать столбцы `Status` как Foreign Key, что будет занимать меньше памяти в БД (наверное, так как не нахожу информации, но как мне кажется это будет ссылка 1 байт) что будет всего 100MB.

При селекте столбец `Status` будет использоваться во всех таблицах постоянно, и меняться тоже будет немного реже селекта, но тоже часто.

Уникальных статусов будет не больше 200 штук.

Посоветуйте как будет лучше?
Писать просто число, или всё же внешняя ссылка?

0

Сообщение от Andrey-MSK или у вас есть таблицы с long в ID?

Да.

Сообщение от BeginnerCoderCS public long Id {get; set;}

Как минимум в двух случаях, или много записей планируется, или во внешнем API сервисе уже Id не вмещаются в int.

0

Вы бы пояснили, что у Вас за "Статус" такой, что есть во всех таблицах ?
Сдается мне, что он связан с признаком записи: новая, удалена, изменена. Если так, то идея дрянь. Нужно вести журнал для всей БД. И писать туда при любом изменении в любой таблице. Делать это в триггерах. Журнал будет большой, но тормозить сильно не будет. У нас был такой реализован в MS SQL. Около 200 таблиц, журнал около 100 млн.записей. Туда - только Insert. Зато можно наблюдать полную историю изменений в любой таблице: когда, кто и что изменил. Конкретно.
Плюс служебная программка для его просмотра и анализа.

ЗЫ. Конечно, в Ms SQL есть "штатный" лог. Но работать с ним - сущий ад. Кто это делал, то меня поймет

0

Сообщение от MsGuns что у Вас за "Статус" такой, что есть во всех таблицах ?

Самый основной статус это занятости записи.
Так как будет использоваться несколько приложений, то чтобы случайно запущенное приложение не начало выполнять задачу, которая уже выполняется.

К примеру у нас несколько аккаунтов, и нам нужно с какой-то периодичностью получать погоду с сервиса.
Но чтобы случайно другой экземпляр или другое приложение не начало выполнять то же самое, нужно установить состояние BUSY, а после получения данных устанавливаем на OK, или если не удалось то устанавливаем в BAD.

UserId;Service;Status
User1;GetWeather;OK
User2;GetWeather;BUSY
User3;GetWeather;OK


Да получается один SELECT и два UPDATE на каждую запись.
Ничего больше не придумал для очереди.

0

BeginnerCoderCS, Для подобных проблем есть транзакции.
То, что пытаетесь соорудить, есть чудовищные грабли.

1

Сообщение от MsGuns Для подобных проблем есть транзакции.

Допустим есть таблица `Книги`, и есть таблица `Страницы`.
В каждой книге есть большое количество страниц, и пока мне их все перечитать, мне нужно установить на конкретную книгу статус BUSY чтобы другой поток или другое приложение не получило эту книгу, а получило следующую.

Мне кажется здесь не получится использовать транзакции, так как на выполнение одной `книги` нужно 10-20 минут. Слишком много времени, чтобы блокировать БД.
Тем более, после взятия `Книги` и установки BUSY, идёт чтение, запись, изменение объектов из таблицы `Страницы` и т.д.

Я не доказываю, что это вернейшее решение.
Если есть что-то проще|лучше|надёжнее, я готов попробовать.

0

Сообщение от BeginnerCoderCS Самый основной статус это занятости записи. Так как будет использоваться несколько приложений, то чтобы случайно запущенное приложение не начало выполнять задачу, которая уже выполняется.

Ой-ой-ой. Вот это костылина)

Такие вещи делаются через общий сервер приложения, который может отследить кто из клиентов что запрашивает и вести учёт "блокирования" записей в памяти, без загаживания базы.

0

Сообщение от Usaga Ой-ой-ой. Вот это костылина)

Мне это чуть больше года назад посоветовали, вот так и использую. Привык и думаю что это норма

Сообщение от Usaga Такие вещи делаются через общий сервер приложения, который может отследить кто из клиентов что запрашивает и вести учёт "блокирования" записей в памяти, без загаживания базы.

Ткните носом.
Может есть где-то проект с примерами?
Или хотя бы что гуглить?

p.s. Как видите, по моим вопросам, у меня часто возникают глупые мысли, которые мне не дают покоя. Но часто выходит что не зря они не дают покоя, так как путь был неправильный ))
Так что я готов к критике, вы не стесняйтесь. Особенно с нужными пинками

0

Сообщение от BeginnerCoderCS Или хотя бы что гуглить?

Это центральный элемент "трёхзвенной" архитектуры. Сервис, без UI, через который все клиенты и работают. Клиенты могут иметь любую природу (консолька, WPF, мобилка, браузер). Вся бизнес-логика и обращения к базе хранятся именно там.

Соответственно, раз все запросы идут через этот сервер, то он всегда знает, кто что запрашивает.

1

Сообщение от Usaga Соответственно, раз все запросы идут через этот сервер, то он всегда знает, кто что запрашивает.

Судя по тому что он сказал что приложений может быть много, то вариант не подойдёт.

Сообщение от BeginnerCoderCS Так как будет использоваться несколько приложений, то чтобы случайно запущенное приложение не начало выполнять задачу, которая уже выполняется.

Обсуждали как-то задачку по блокированию данных в таком случае.

0

Сообщение от HF Судя по тому что он сказал что приложений может быть много, то вариант не подойдёт.

У каждого приложения сделать свою подпись, и сервер всё узнает по этому флагу.

0

Сообщение от HF Судя по тому что он сказал что приложений может быть много, то вариант не подойдёт.

Рояли не играет никакой: то ли 100 юзеров запустят одно и то же приложение, то ли один юзер запустит у себя на ПК 100 разных приложений.
Для сервера это равнофиолетово

Добавлено через 3 минуты
У него Книга из 100 млн страниц. Он хочет, чтобы если ее кто-то "открыл", то для других она бы была недоступной до тех пор, пока этот "кто-то" ее не "закроет". Сама по себе идея абсурдная. Реализация, похоже, ничем не лучше

0

Допустим есть 5 приложений по управлению интернет магазинами.
Run1 - добавляет товары в магазин
Run2 - удаляет товары из магазина
Run3 - собирает статистику по товарам в других магазинах
Run4 - изменяет цену товара на основе статистики
Run5 - выгружает статистику продаж\цен и т.д.


У всех своя периодичность запуска, или запуск по какому-то событию, или запуск от пользователя.

Допустим запускается по событию Run1 и начинает добавлять товары.
И в этот же момент пользователь решил запустить это же приложение.
Если оба отработают, то добавят дубли товаров.
Если удалить их из источника раньше, чем добавить в БД, есть возможность потерять данные.

Но в это время все остальные от Run2 до Run5 могут выполянть свои действия.


Потом запустился сбор статистики из других магазинов Run3, если ещё по каким-то причинам запустится ещё одно приложение (пользователь и т.д.) то опять же добавится статистика с дублями, которая полностью испортит калькуляцию расчёта приложения Run4.

И в свою очередь вторая копия Run4 изменит цену товара в зависимости от изменения первой копии Run4, что приведёт или к большой цене и низким продажам, или к низкой цене и сливу денег.
А при неэффективности, товар будет удалён приложением Run2, и опять же, если запускать несколько раз, то будут сыпаться ошибки. И как я понимаю, лучше не удалять данные, а просто им поставить статус `DELETE`.


А вот Run5 будет подымать нагрузку на БД, так как будет содержать много JOIN-ов.
Влияния на данные у него нет, а вот нагрузка да, так что и его тоже лучше контролировать, чтобы не было повторных выборок.


Здесь самое регулярное это конечно изменение цен товаров и сбор статистики.

Сообщение от MsGuns У него Книга из 100 млн страниц. Он хочет, чтобы если ее кто-то "открыл", то для других она бы была недоступной до тех пор, пока этот "кто-то" ее не "закроет".

Немного не так.
Если определённая задача уже выполняется над определённой книгой(магазином), то другое приложение не должно делать то же самое.
Но другие задачи с этими книгами (магазином) могут выполняться.

И если у нас 10 магазинов, и приложение упало на 4-м магазине, то при повторном запуске, начнётся обработка именно 4-го магазина, и продолжится 5, 6 и т.д., а не будет менять постоянно с 1-го.

Сообщение от Usaga Это центральный элемент "трёхзвенной" архитектуры.

Я правильно понимаю это вы о сервисе API между БД и приложениями?

То есть получается вы предлагаете делать всё то что я описал, только ни в самой БД, а в памяти в сервисе API?
А что делать, если сервер упал, или пользователь перезагрузил сервер? Как узнать какие данные уже изменены, а какие ещё нужно менять.
Или я не правильно понимаю, и вы вообще не так предлагаете?

Сообщение от MsGuns Сама по себе идея абсурдная. Реализация, похоже, ничем не лучше

Всё возможно. Если есть какие-то зарекомендовавшие себя способы, то озвучьте пожалуйста.

Сообщение от HF Обсуждали как-то задачку по блокированию данных в таком случае.

Так как знака вопроса нет, то думаю это предложение. Давайте подробнее.

Сообщение от Andrey-MSK У каждого приложения сделать свою подпись, и сервер всё узнает по этому флагу.

Да, но почему это не хранить в самой БД?


p.s. Жду любые предложения, и не пытаюсь доказать что мой метод лучше всех.
С предложениями не стесняйтесь, даже с такими же абсурдными как мои
Если с примерами, то ещё лучше

0

Сообщение от BeginnerCoderCS Так как знака вопроса нет, то думаю это предложение. Давайте подробнее.

Вкратце - вы так не сможете сделать, так как всегда будет возможность кому-то извне что-то сделать.

Если проще - то вам надо на уровне БД устанавливать блокировку на нужную таблицу/строку.

И тогда все ваши Status.есы которые вообще не имеют ничего общего с самой моделью, потеряют смысл. Они и сейчас то смысла не имеют. Пример, я открываю другое приложение и делаю DELETE WHERE ID=... и мне всё равно какой у вас там Статусес. Панимаете?

А из этого ещё вытекают такие важные решения как то: прекратить доступ всем кроме доверенного сервиса; или разграничить права на запись через роли по пользователям БД; или забить на всё так как ХХ приложений они все ваши и вы сами будете виноваты если они одновременно у вас пишут в одно место и т.п.

Добавлено через 4 минуты

Сообщение от BeginnerCoderCS Допустим есть 5 приложений по управлению интернет магазинами. Run1 - добавляет товары в магазин Run2 - удаляет товары из магазина Run3 - собирает статистику по товарам в других магазинах Run4 - изменяет цену товара на основе статистики Run5 - выгружает статистику продаж\цен и т.д. У всех своя периодичность запуска, или запуск по какому-то событию, или запуск от пользователя.

Блин. Вы хотите придумать свою реализацию микросервисов?

И заметтье, что

Сообщение от BeginnerCoderCS Run1 - добавляет товары в магазин Run2 - удаляет товары из магазина Run4 - изменяет цену товара на основе статистики

На самом деле это сервис Одной ответственности. Изменение Товаров.

Сообщение от BeginnerCoderCS Run3 - собирает статистику по товарам в других магазинах Run5 - выгружает статистику продаж\цен и т.д.

а это Другая ответственность - тупо статистику собирать (рид-онли) по сути. И доступ на запись не нужен.

0

Сообщение от HF Run3 - собирает статистику по товарам в других магазинах

Не суть, но имелось в виду статистику товаров магазинов конкурентов. То есть будет и писать.

Сообщение от HF На самом деле это сервис Одной ответственности. Изменение Товаров.

То есть вы предлагаете сделать одно приложение, которое будет всё это выполнять?
А как быть, если нужна разная периодичность?
Где хранить данные когда что-то делать, а когда нет?

Сообщение от HF Блин. Вы хотите придумать свою реализацию микросервисов?

Ну вообще не планировал. А что похоже? По-моему нет )

Сообщение от HF Если проще - то вам надо на уровне БД устанавливать блокировку на нужную таблицу/строку.

Ну так мне не нужно её блокировать. Мне нужно не дать приложениям делать параллельно одну и ту же работу.
И блокировка на уровне БД это уже не про микросервисы как я понимаю.

Сообщение от HF я открываю другое приложение и делаю DELETE WHERE ID=... и мне всё равно какой у вас там Статусес. Панимаете?

У меня устанавливается статус DELETE, а запись не удаляется.
Так как приложению статистики нужны все записи, хоть рабочие, хоть нет.

Да, можно сказать, что у каждого приложения должна быть своя БД, но там очень много данных, которые должны находиться в одной БД.


Мне кажется, что это не такая уже необычная задача.
Неужели нет реальных примеров, где одновременно работают несколько приложений с одной БД?
Если это не велосипед, тогда это революция

0

Сообщение от BeginnerCoderCS Ну так мне не нужно её блокировать. Мне нужно не дать приложениям делать параллельно одну и ту же работу.

Нет слов. Это и есть блокировка возможности приложения не сделать изменения в одну и ту же запись одновременно.

Не хотите дать возможность "приложениям делать", то значит нужен единый сервис блокировки ИХ действий. Раз вы ничем не управляете то что вам остаётся? Только последний рубеж - сервер БД.
Сами себя загоняете в угол и предпринимаете попытки убежать, а не придумываете чёткое решение.

0

BeginnerCoderCS, Я почитал Ваше [32] со всеми этими ранами.. Налицо почти полное незнание предметной области. Интернет-магазин - это не только и не столько красивые картинки с сервисами, но еще и довольно строгая бухгалтерия, движение средств, склад и движение по нему, ведение прайсов и т.д. Сам магазин - это лишь витрина с возможностью сделать заказ "на лету". А "под ним" сложная система строгой учетности. О которой, Вы, как мне представляется, не имеете розового представления.

0

HF, MsGuns, так скажите как нужно делать?
Пока вы говорите только то, что я делаю неправильно, но не говорите как сделать правильно.
Как-будто есть два пути, и я иду не по тому. Но их не два, их миллион, и все перебрать не смогу (жизни не хватит).

Статусы для записей я в своё время тоже не хотел принимать, но потом привык, и думал что так делают все ))
Но если есть всем известные правильные решения, то закидайте меня пожалуйста фактами.

0

Сообщение от BeginnerCoderCS как нужно делать?

Если в двух словах, изучите тщательно документооборот торговой фирмы - все типы документов. И пляшите от них.

0