Склад. Как лучше учитывать товары?

То есть, это таблица хранящая все названия (виды) когда-либо поступивших на склад товаров.

А почему вы его не назвали Товары?) Просто интересно. Может быть мне тоже назвать номенклатура...

Теперь мне более менее понятно)) Можете ещё помочь с терминологией самих таблиц? Как бы вы назвали в базе данных эти таблицы?

Приход - purchases
Расход - shipments
Списание - losses
Остатки - reports
Инвентаризация - inventories

Склад. Как лучше учитывать товары?

Вы очень хорошо все расписали. Очень вам благодарен)

Подскажите ещё:

1. Что нужно помещать в Номенклатуру? И как будет проходить Инвентаризация? Это отдельная таблица?
2. Что вписывать в приходной и расходной накладной?
3. Акт списания обязателен?) Я так понимаю, акт списания это доп. таблица с актами или это просто номер акта?
4. Почему нельзя сделать просто таблицу Историй, где будем фиксировать истории по типу (Расход, Приход)? Большая нагрузка?

Хорошо, если бы так же расписали все тонкости. У меня они будут немного другие, но ваша логика мне понравилась)

Как правильно построить архитектуру?

xmoonlight, ахах. Блин)) Я реально голову сломал уже. Примеров таких подобных нет. Прогуглил. Вебинар хороший. Толковый парень. Но я не понял как это применить ко мне. В других задачах понимаю. А тут нет. С Википедии тоже не особо понял. Мозги вроде есть, но как будто нет

Как правильно построить архитектуру?

xmoonlight, поизучай я деревья)) Да, тема обширная. Капец как сложно))) Смотрел вот этот вебинар Но я все равно не понял как это можно применить к моему случаю.

Как организовать онлайн образование?

xmoonlight, ахах))) С деревьями разбираюсь)) Я думаете забыл про это?) Знакомые просто попросили узнать у сообщества интересующий их вопрос.

Как правильно построить архитектуру?

xmoonlight, да примерно понимаю) просто я привык мыслить агрегатами, сущностями, свойствами, а тут что-то новое))) Разберусь, думаю) Надо завтра нашу лекцию с утра почитать на свежую голову и дойдёт)

Как правильно построить архитектуру?

xmoonlight, спасибо за помощь! Завтра буду изучать эту тему более детально)

Ответ решением помечу чуть позже, если не против. Ну или сами можете пометить чуть позже. Вдруг кто-то ещё накидает ответов или кинет примеров)

Благодарю!

Как правильно построить архитектуру?

xmoonlight, что касается станет ли это отправкой к познанию деревьев, то тут просто. Знаком C nested sets. Если мне поможет в решении данная тема и так оно действительно должно быть, то это точно, что я её буду изучать. Так как над подобной задачей уже мучаюсь около трёх месяцев. Как сделать просто и быстро знаю, но хочется сделать правильно и хорошо. И если ещё узнаю что-то новое - будет плюс в двойне. Пишу на symfony и доктрина.

Как правильно построить архитектуру?

xmoonlight, Мне писать код не нужно) Сам с телефона и понимаю Вас) С этой темой не знаком от слова вообще. Поэтому я и не понял ваш ответ) Мне главное понять суть, а дальше я накопаю. Наверняка есть какие-то видео разборы на примере кода. Наверняка у вас есть подобное в личной базе знаний. Буду рад если поделитесь этими ссылками. Потому что я прочитал статьи на хабре про узлы, но это не совсем понятно. И пример там был математический. Он далёк от моей.

Как правильно построить архитектуру?

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

Про паттерн наблюдателя понятно в целом. Проблема именно в понимании граф узла на коде. Почитал статьи на эту тему. Но больше понимаю через код)

Как правильно построить архитектуру?

xmoonlight, понятно) то есть плодить много сущностей по разному типу не требуется? Но такой объект будет со временем увеличиваться в размерах. Разные поля будут использоваться в зависимости от типа мероприятия. А если мне потребуется много свойств в таком объекте? Объект будет иметь несколько тысяч строк. Разбираться в таком объекте будет сложно.

К тому же есть такой факт, что 1 событие может иметь несколько других событий. В главном событии сводится вся статистика и управление.

Как правильно построить архитектуру?

xmoonlight, просто я выше писал примерно такой вариант:

Мероприятия
	Событие
		Id
		Name
		Despription
		Status
		Periods //Периоды дат, к которым привязаны все типы. Например, Фестиваль проходит с 10-12-2020 по 11-12-2020 и с 20-12-2020 по 21-12-2020
		
		Соревнование
			Id
			PeriodId
			Name
			Status
			OrganizerId
			OrganizationId
			Plases //Площадки 1 или больш

			Регистрация
				//Система регистрации
			Счёт
				//Система счёта
		Мастер-класс
			id
			PeriodId
			Name
			MentorId
			Status
			OrganizerId
			OrganizationId
			IsCertification
			Prices

			Регистрация
				//Система регистрации
			Счёт
				//Система счёта
		Батлы
			id
			PeriodId
			Name
			Status
			OrganizerId
			OrganizationId
			Nominations
			Juges

			Регистрация
				//Система регистрации
			Счёт
				//Система счёта

Связь по UUID (id)

Но вы почему-то стали говорить как я понимаю узел) Вот я и подумал, что не то. И говорю вам, что так не делал. Поэтому, я скорее всего не имею такого опыта или понимания) С узлами в терминологии не приходилось встречаться....

Как правильно построить архитектуру?

xmoonlight, например, так

Event
 - id
 - parent_id //or group_id

Как правильно построить архитектуру?

xmoonlight, кстати. У меня такая же проблема с персонами этих всех мероприятий. Есть: участники, организаторы, лекторы, наставники и т д. С одной стороны их можно всех обьединить в одно - персоны. Но с д другой стороны у них могут быть/или не быть какие-либо данные. Например, у участника может быть закреплённый наставник. А у остальных наставников быть не может.

С этим я тоже застрял. Проблема прохожая. И решение тоже, думаю.

Как правильно построить архитектуру?

xmoonlight, Узел графа - объект, который связан или соединен с одним или несколькими другими объектами, как я понимаю. Если вы об этом. Если говорить честно, то я никогда не сталкивался с таким толкованием, поэтому и потерялся)

Что касается ника - это не показатель уровня познаний. Выбрал этот Ник, так как мой стандартный был занят. А этот был свободен.

Узел - имеет свой тип и содержит свои свойства в зависимости от выбранного типа.

Исходя из этого создаём объект События, со своим типом. У него есть разные фабричные методы или фабрики как это объект создаётся в зависимости от типа мероприятия. Каждый тип имеет свои свойства, которые ему нужны. Но объединено это все в одном объекте. Так? Или что-то не то понял? Просто вы ещё говорили про события и синхронизацию данных. Тут я совсем не понял. В общем я что-то запутался)

Может быть есть какие-то примеры? Чтобы не на словах, а на коде понять?)) Спасибо за помощь!

Как правильно построить архитектуру?

Не совсем из вашей терминологии понял объяснение. Если брать DDD, то узел это агрегат? Или что это?

Правильно ли я понял, что мы создаём

Сущность «Событие», к которому привязаны вспомогательные сущности по типу: соревнования, мастер-класс... Я правильно мыслю все таки или нет?

К сожалению не смог разобраться с вашим ответом(

Что не так с выборкой дат?

idShura, В базе дата хранится в DATETIME. ВСе уже много раз проверил, но не хочет)

Что не так с выборкой дат?

idShura, нет

Что не так с выборкой дат?

idShura, ну не скриншотам же мне данные сюда кидать)) Вот из этих двух строк выводятся обе. А не одна Пробовал всяко. Не работает почему-то у меня(((((((

Что не так с выборкой дат?

idShura, все верно. Но в итоге у меня в списке, после выборки, есть дата, которая имеет год 2021. (2021-03-17 00:38:38) Почему так происходит?