PS
Если нам ок потеря точности, то делить просто.
Если ок деление с остатком то тоже просто.
Size: a a a
2021 March 07
E
допустим мы делаем банк
Делая банк - храним в минимальной денежной единице, например в копейках
PS
Evgen
Делая банк - храним в минимальной денежной единице, например в копейках
а как производить деление / проценты?
E
а как производить деление / проценты?
С округлением по банковским правилам до минимальной денежной единицы
ИМ
чуваки, у меня утечка памяти в explorer.exe
ИМ
вроде проводник работает, все окей, но когда перехожу в раздел "загрузки" он намертво зависает
ИМ
никто не сталкивался??
EK
Может, диск умирает?
ИМ
Может, диск умирает?
ssd только пол года
МС
вроде проводник работает, все окей, но когда перехожу в раздел "загрузки" он намертво зависает
скорее всего бытие видео файлы, недокаченные?
нужно попробовать удалить total commander-ом. Ему пофиг на формат файлов...
нужно попробовать удалить total commander-ом. Ему пофиг на формат файлов...
ИМ
слушайте, у меня час назад свет вырубили, вместе с ним и ПК. Мб из за этого?
ИМ
ток заметил
МС
а, тогда это проблема файлов системы, нужно проверить
МС
chkdsk c: /f
ИМ
очистил загрузки, заработало, спасибо всем огромное!
НМ
Привет! Подскажите, пожалуйста по правильной архитектуре.
Использую noSQL БД - MongoDB
Суть такая, хочу для музея создавать мероприятия, далее распределять мероприятия по дням , далее люди смогу из клинетской части записываться на события и оплачивать бронь (покупать билет) . Пользователь может забронировать сразу несколько разных мероприятий на разных датах.
Получаются следующие модели в MongoDB:
1) Мероприятие, в схеме которого основные данные, вроде описания, длительности, максимальное количество человек, картинки и двусторонняя связь с Датами, на которых будет событие.
2) Дата, где количество записей на этот день, связанное с моделью Бронирования и связь с самим событием. Вопрос, нужно ли тут дублировать в схеме информацию из основного события, в виде длительности, названия и стоимости? Или просто отдельным запросом через связь получать информацию?
3) Бронирование, где уникальная ссылка, связь с Датой и Связь с пользователем. Вопрос, нужно ли дублировать информацию из связанной модели Даты или получать отдельным запросом?
4) Пользователь, связанный с бронированием.
Такая организация сама по себе нормальна? Не избыточна?
Использую noSQL БД - MongoDB
Суть такая, хочу для музея создавать мероприятия, далее распределять мероприятия по дням , далее люди смогу из клинетской части записываться на события и оплачивать бронь (покупать билет) . Пользователь может забронировать сразу несколько разных мероприятий на разных датах.
Получаются следующие модели в MongoDB:
1) Мероприятие, в схеме которого основные данные, вроде описания, длительности, максимальное количество человек, картинки и двусторонняя связь с Датами, на которых будет событие.
2) Дата, где количество записей на этот день, связанное с моделью Бронирования и связь с самим событием. Вопрос, нужно ли тут дублировать в схеме информацию из основного события, в виде длительности, названия и стоимости? Или просто отдельным запросом через связь получать информацию?
3) Бронирование, где уникальная ссылка, связь с Датой и Связь с пользователем. Вопрос, нужно ли дублировать информацию из связанной модели Даты или получать отдельным запросом?
4) Пользователь, связанный с бронированием.
Такая организация сама по себе нормальна? Не избыточна?
GS
Привет! Подскажите, пожалуйста по правильной архитектуре.
Использую noSQL БД - MongoDB
Суть такая, хочу для музея создавать мероприятия, далее распределять мероприятия по дням , далее люди смогу из клинетской части записываться на события и оплачивать бронь (покупать билет) . Пользователь может забронировать сразу несколько разных мероприятий на разных датах.
Получаются следующие модели в MongoDB:
1) Мероприятие, в схеме которого основные данные, вроде описания, длительности, максимальное количество человек, картинки и двусторонняя связь с Датами, на которых будет событие.
2) Дата, где количество записей на этот день, связанное с моделью Бронирования и связь с самим событием. Вопрос, нужно ли тут дублировать в схеме информацию из основного события, в виде длительности, названия и стоимости? Или просто отдельным запросом через связь получать информацию?
3) Бронирование, где уникальная ссылка, связь с Датой и Связь с пользователем. Вопрос, нужно ли дублировать информацию из связанной модели Даты или получать отдельным запросом?
4) Пользователь, связанный с бронированием.
Такая организация сама по себе нормальна? Не избыточна?
Использую noSQL БД - MongoDB
Суть такая, хочу для музея создавать мероприятия, далее распределять мероприятия по дням , далее люди смогу из клинетской части записываться на события и оплачивать бронь (покупать билет) . Пользователь может забронировать сразу несколько разных мероприятий на разных датах.
Получаются следующие модели в MongoDB:
1) Мероприятие, в схеме которого основные данные, вроде описания, длительности, максимальное количество человек, картинки и двусторонняя связь с Датами, на которых будет событие.
2) Дата, где количество записей на этот день, связанное с моделью Бронирования и связь с самим событием. Вопрос, нужно ли тут дублировать в схеме информацию из основного события, в виде длительности, названия и стоимости? Или просто отдельным запросом через связь получать информацию?
3) Бронирование, где уникальная ссылка, связь с Датой и Связь с пользователем. Вопрос, нужно ли дублировать информацию из связанной модели Даты или получать отдельным запросом?
4) Пользователь, связанный с бронированием.
Такая организация сама по себе нормальна? Не избыточна?
Не разбираюсь в проектировании ДОБД, но выглядит, как типичная задача для РБД