Как-то не очень с классификациями. Подчеркивания, смешивание логических уровней и так далее. Связи между сущностями - ок, они всегда могут быть, а иерархию эту с иллюстрации лучше бы не рисовали.
Думается, есть тенденция смешивать в кучу токсичность, хамство и откровенность.
Токсичность в узком смысле - манипулятивность. Впрочем, любое высказывание может служить манипулятивным целям. Ну так, чисто математически рассуждая :)
Ясное дело, что этих роботов тоже пробьют. Но хоть откровенного мата не будет :)
Второй, четвертый и пятый пункт должны быть всегда выполнены по умолчанию, да и третий с первым надо планировать на берегу, по-хорошему, но да, согласен.
Докину еще реплицирование на отдельную машину для аналитики, постоянный перерасчет накапливаемых данных и/или типовых выполняемых запросов, денормализацию (если это оправдано) для ускорения запросов, переписывание запросов с использованием временных таблиц (бывает куда быстрее посчитать нечто в 2-3 этапа, чем одним запросом).
Вы планируете ежесуточно или в текущем режиме? На сколько дней вперед? Из текста можно составить мнение, что формируется заявка на отправку конкретного вагона, тогда по какому событию?
Какие СУБД используются?
Порядок величины парка вагонов? До 1 тыс, до 10 тыс и т.д.
"я был одним из их самых опытных сотрудников и полагал, что у меня будет какое-то влияние, чтобы продолжать работать"
популярное заблуждение... бизнес, он такой, он не ведется на попытки работника стать незаменимым (а еще и с удовольствием оставят управляемого тупенького новичка вместо поседевшей звезды, которая в глаза говорит гадкое и светится умом)
Жаль, что чел на своем опыте познал это в таком серьезном возрасте.
То, что у разных задач разный маршрут в "документообороте" и разный набор атрибутов, отнюдь не запрещает им быть в одной таблице. Ну это так, к слову.
А вот "иметь одну запись, в которой указан последний выданный id " - проверенный практикой рациональный вариант. Он приближает вас к решению задачи обеспечения уникального сиквенса в рамках распределенной по нескольким серверам системы (с возможностью автономной работы/с не гарантированно работающими каналами связи).
Ну и если забыть про существование триггеров и тому подобных измышлений больного ума, станете ближе к кроссплатформенности в смысле СУБД.
Как-то не очень с классификациями. Подчеркивания, смешивание логических уровней и так далее. Связи между сущностями - ок, они всегда могут быть, а иерархию эту с иллюстрации лучше бы не рисовали.
Думается, есть тенденция смешивать в кучу токсичность, хамство и откровенность.
Токсичность в узком смысле - манипулятивность. Впрочем, любое высказывание может служить манипулятивным целям. Ну так, чисто математически рассуждая :)
Ясное дело, что этих роботов тоже пробьют. Но хоть откровенного мата не будет :)
На любом собеседовании человек, который с лету отвечает на все вопросы, обычно overqualified. И в "эту чудесную компанию" работать не пойдет.
Второй, четвертый и пятый пункт должны быть всегда выполнены по умолчанию, да и третий с первым надо планировать на берегу, по-хорошему, но да, согласен.
Докину еще реплицирование на отдельную машину для аналитики, постоянный перерасчет накапливаемых данных и/или типовых выполняемых запросов, денормализацию (если это оправдано) для ускорения запросов, переписывание запросов с использованием временных таблиц (бывает куда быстрее посчитать нечто в 2-3 этапа, чем одним запросом).
Наверное, потому же, почему в интерфейсе электронной переписи Росстат налепил кучу пунктуационных и стилистических ошибок.
А какие есть еще варианты, помимо самого трудозатратного? И в каких случаях создание партиций оправдано?
Спасибо.
Интересно. Если позволите, несколько вопросов.
Вы планируете ежесуточно или в текущем режиме? На сколько дней вперед? Из текста можно составить мнение, что формируется заявка на отправку конкретного вагона, тогда по какому событию?
Какие СУБД используются?
Порядок величины парка вагонов? До 1 тыс, до 10 тыс и т.д.
"В каком полку служили?!"
"я был одним из их самых опытных сотрудников и полагал, что у меня будет какое-то влияние, чтобы продолжать работать"
популярное заблуждение... бизнес, он такой, он не ведется на попытки работника стать незаменимым (а еще и с удовольствием оставят управляемого тупенького новичка вместо поседевшей звезды, которая в глаза говорит гадкое и светится умом)
Жаль, что чел на своем опыте познал это в таком серьезном возрасте.
То, что у разных задач разный маршрут в "документообороте" и разный набор атрибутов, отнюдь не запрещает им быть в одной таблице. Ну это так, к слову.
А вот "иметь одну запись, в которой указан последний выданный id " - проверенный практикой рациональный вариант. Он приближает вас к решению задачи обеспечения уникального сиквенса в рамках распределенной по нескольким серверам системы (с возможностью автономной работы/с не гарантированно работающими каналами связи).
Ну и если забыть про существование триггеров и тому подобных измышлений больного ума, станете ближе к кроссплатформенности в смысле СУБД.
Судя по KPI для высокоинтеллектуальных работников, уже.