Именно это и хотел указать. 4 таких универсальных регистров и вместо двух у вас уже 32. И с каждым новым дополнительные 8. И так по нарастающей. А у Ардуино как были два выхода использованы - один под такт, другой под данные, так и будут - не важно будете 4 регистра использовать или например 10. В последнем случае у вас уже 80 выходов гарантировано. Думаю - хватит.
Так как никто из нас не знает, что у тебя в таблицах лежит- никто конкретно не скажет, почему. Но. Всегда надо тдти от простого к сложному. Вначале делаешь селект на одну таблицу. Получил нужное кол-во строк, подсоеденяешь следующую таблицу итд. Понятно, что у тебя при каком-то из этих left join(ов) преумножается кол-во из-за того, что в смежной таблице не одна строчка приходит, а две. Например потому, что эти две строчки с разными статусами жизненного цикла этой энтитеты....и этот статус надо тоже например указывать при left joine
и всю дорогу думал о переполнении контейнеров, даже, если в продолжении стояло про вещественные числа. Ответ и правда какой-то бред. Как такое задание можно вообще составить?
Алексей Коваленко, ну товарищь, так тоже нельзя. Какую-то коммерческую работу вы хотите другими руками сделать. При этом не слушаете, а с гонором отвечаете - это так себе. Никому не захочется вам после этого помогать.
Не по теме вопроса, но рандомизацию я-бы дополнил из опыта проведения прошлых секций. Если человек хочет взять на себя аакое-то время, но раз за разом не выполняет условия и например тренировка отменяется, то после таких пару 'киданий' надо вероятность выбора тренера уменьшить. Соблюдается какое-то количество тренировок, то и коэффициент выбора возвращается на нормальное значение. Вишенка сверху, когда сюда и отзывы о качестве тренировок превносятся.
Самый правильный вариант. Новые объекты без проблем вводятся в игру. Единственное, что мне в голову приходит, что этой моделью не удовлетворить - это линия отзыв на комбинацию (препод+курс). Хотя наверное и это тоже можно сделать, тк. где-то ведь хранится запись, что какой-то курс в какое-то время каким-то преподавателем ведётся. И именно эта сущность тоже кодируется и именно эта комбинация может быть тоже получить отзыв. Те. - подтверждаю ваш концепт и с моей стороны.
Gatix, я Вам ответил в другом комментарии, а здесь задам к Вашим словам вопрос. А как Вы себе представляете процесс новых версий программы? Ведь как-бы вы не хотели, будут или ошибки, которые надо будет исправить, или важные новые функции, или трендовые хотелки, за которые клиенты и деньги будут готовы выложить итд. Ведь все эти конфигурациями, которые Вы ручками вбивать хотите - это просто ума времени и гора возможных ошибок.
Ради интереса, с postgrepro не работаю, просто для себя прикинул, как бы я это решил в других базах с другим SQL. Насколько быстро работает эта оконная функция?
edward_freedom, согласен по теме вашего ответа. Просто в моем случае, конечно объекты, со всеми другими объектами можно, иногда даже и нужно в json сбрасывать. Тот случай, который описал я - там чуть ли не всю базу данных в один json сбрасывают. Это уже просто по моему мнению извращение над технологией. Но - это уже другая тема.
edward_freedom, ага, у нас с такими обьяснениями - csv есть прошлый век - создали JSON файл весом больше 3 ТБ, потом перекидывают это с одной машины на другую и удивляются, что потом не хватает ночного времени всё распарсить. В нём 90% - это тэги. И структура меняется раз в три года. Банальным "старомодным" csv всё было-бы намного проще, но - увы, кто-то подгодит не по степени надобности и возможности, а количеству годиков. Но это к заглавному вопросу не имеет ничего общего. Против вашего предложения технологии - JSON - не имею ничего против, просто ваше обьяснение улыбнуло.
Уверен, что должно быть три таблицы- 1. Физ.лицо, 2.образование, 3. Соединение 1-ой ко 2-ой,
Максимальность по образованию должно хранится во 2-ой таблице, дата получения образования в 3-ей.
При выводе ко всему, что тебя интересует добавляешь сортировку для долнейшего ограничения по ней где-то так
SELECT * FROM (
SELECT
X,....
ROW_NUMBER() OVER(PARTITION BY
T1.PID (перзон-ид) ORDER BY max( T2.OPRIO /по образованию) , T3.ODAT /дата получения AS SRC_NR
FROM
T1,T2,T3
WHERE T1.PID =T2.PID AND T2.OID = T3.OID
) SRC
Всё надо и хранить, и организовывать через базу данных. И продукты, и их сроки действия и актуальный статус. И показ в зависимости от статуса. Но, если исторические какие показы происходят, то да, в этом случае и неактивные элементы в списках показываются, но уже не для изменения а именно для того, как это было например год назад - с каким продуктом например был тот или иной ордер.
Сергей Кузнецов, может быть я ошибаюсь но именно trim как раз-таки и делает возможным восстановление данных. Тк. при включённом или при наличии trim участки на ssd не затираются, а как вы и написали просто помечаются как неиспользованные. Это увеличивается скорость 'удаления' и сохраняется продолжительность жизни nand ячеек, тем, что они лишний раз не перезаписываются. Но ведь этим -то и сохраняется прежниее состояние в ячейках. Я не в теме, но уверен что есть побайтовые читалки для всех ячеек ssd. И если они сохранены, то и восстановить кое-что будет всегда возможным. Но могу ошибиться.
Простое записывание новых данных на носители не гарантирует, что это на то же самое место будет происходить, где лежал старый файл. Но вы указали- на весь возможный объём памяти, то уверено скажу - да.
