Попробуйте Clojure. Он может и не идеал но достаточно красивый язык. Вот видео для вдохновения от создателя Clojure. Видео будет полезно для всех. Там общие принципы.
Спасибо за статью. Мне интересно что посоветуете в моем случае. С точки зрения хорошей архитектуры. И потенциально огромной таблицы. Правда сейчас это не хайлоад и там не так много записей. Есть таблица товаров и у товаров есть таблица ивентов. Ивенты: created, moderated, updated, sold. И вот для ивента moderated я хочу хранить дополнительно кто промодерировал, а для sold кому продали и цену продажи. Я пришел к тому что просто добавил колонки sold_to где пользователь кому продали и price цена за которую продали и moderated_by где пользователь который промодерировал. Но для большинства записей в таблице ивентов, такие как created или updated эти колонки заполнены нулами. Это нормально или как мне сделать лучше если по этим полям (sold_to, moderated_by, price) поиск производиться не будет и показывать их тоже надо будет в исключительных или редких случаях?
Насчет продуктов понял ваш тезис только вот "а немногие места, где надо обработать скрытые товары" может оказаться что таких мест много, и даже пользователям надо показывать такие товары только с подписью "нет на складе" и в таком случае флаг будет лучше. И еще, если мы делим на 2 сущности то при добавлении новых полей или изменении старых неопределенность увеличилась. В целом конечно нужно думать постоянно, иметь полную статистику по проекту, и точное тз или спецификацию.
Статья понравилась, легко читается и понятные примеры. Есть небольшой вопрос, вот эта часть кода у вас повторяется, стоит ли её вынести и куда лучше вынести если нужно?
if (spellAbility == null) {
throw new Error('NoSpellCastAbility');
}
Попробуйте Clojure. Он может и не идеал но достаточно красивый язык. Вот видео для вдохновения от создателя Clojure. Видео будет полезно для всех. Там общие принципы.
Мне стало интересно что это за такой антисептический препарат. Расскажите?)
так а где хранить кому продали, цену продажи и кто промодерировал? в отдельной таблице?
Спасибо за статью. Мне интересно что посоветуете в моем случае. С точки зрения хорошей архитектуры. И потенциально огромной таблицы. Правда сейчас это не хайлоад и там не так много записей. Есть таблица товаров и у товаров есть таблица ивентов. Ивенты: created, moderated, updated, sold. И вот для ивента moderated я хочу хранить дополнительно кто промодерировал, а для sold кому продали и цену продажи. Я пришел к тому что просто добавил колонки sold_to где пользователь кому продали и price цена за которую продали и moderated_by где пользователь который промодерировал. Но для большинства записей в таблице ивентов, такие как created или updated эти колонки заполнены нулами. Это нормально или как мне сделать лучше если по этим полям (sold_to, moderated_by, price) поиск производиться не будет и показывать их тоже надо будет в исключительных или редких случаях?
Спасибо вам за ваши труды, узнал очень многое с ваших статей. Очень полезная и нужная информация пишите и дальше)
Насчет продуктов понял ваш тезис только вот "а немногие места, где надо обработать скрытые товары" может оказаться что таких мест много, и даже пользователям надо показывать такие товары только с подписью "нет на складе" и в таком случае флаг будет лучше. И еще, если мы делим на 2 сущности то при добавлении новых полей или изменении старых неопределенность увеличилась. В целом конечно нужно думать постоянно, иметь полную статистику по проекту, и точное тз или спецификацию.