Вот на конкретном примере, Вы бы хранили данные о продажах - Вы бы хранили это все на 1 таблице в рамках 1 БД? И начинаю думать по поводу необходимого железа для этой задачи
что файловая система, что база данных -> фактически одни и теже сущности, только заточенные под разные задачи, выдать кусок текста - БД быстрее.
Если мне не изменяет память, то гражданский кодекс РФ признает только одну валюту для расчетов, и это рубль. Интересно, как они будут за USD продавать? =)
Странное заявление, как раз это относится к бэку, настройка переключения языков, выборки данных на нужных языках, или лексиконы, смотря как организована мультиязычность.
Поэтому и спрашиваю, тех кто сейчас крутится в такой среде, может кто что скажет или направит.
когда уже все остальные ушли на управляемые. И по сути одну конфу, это Управление торговлей, так как все задачи только по ней.
так как все задачи только по ней.
Больше нравится WEB Разработка, но только back =)
видимо, есть горе-разрабы, которые не умеют работать с файлами. Вот и пихают всё в базу.
Программа и программный продукт. Программный продукт отличается от программы:
Программный продукт требует в 3 раза больших затрат времени, чем программа (глава 1).
Мифический человеко-месяц. Время выполнения проекта не обратно пропорционально числу программистов, по крайней мере по 2 причинам.
Если есть N программистов, то количество пар программистов равно N(N—1)/2, то есть с ростом числа программистов затраты времени на взаимодействие растут квадратично. Поэтому начиная с какого-то N, рост числа программистов замедляет выполнение проекта.
Если сроки сорваны, наём новых программистов замедляет выполнение проекта и по другой причине: новичкам требуется время на обучение. В книге сформулирован «закон Брукса»: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше».
При очень большом числе программистов проект может быть вообще никогда не закончен: из-за общей неразберихи, попытки исправить существующие ошибки в программном обеспечении порождают новые ошибки, так что система не улучшается (глава 2).
Хирургические группы. Разумно, если в группе разработчиков есть один «хороший» программист, реализующий самые критические части системы, и несколько других, помогающих ему или реализующих менее критические части. Так делаются хирургические операции. Кроме того, по мнению Брукса, лучшие программисты работают в 5-10 раз быстрее остальных (глава 3).
Концептуальная целостность. Для обеспечения концептуальной целостности системы необходимо отделить архитектуру от реализации. Один главный архитектор (или небольшая группа), действуя в интересах пользователя, решают, что должно входить в систему, а что не должно. «Очень крутая» идея может быть отвергнута, если предлагаемая возможность не вписывается в общий дизайн системы. Простота очень важна; может быть полезным реализовать только часть возможностей, на которые способна система, потому что если система слишком сложна, часть её возможностей будет оставаться неиспользованной.
Главный архитектор должен сформулировать свои решения в виде руководства для пользователя (глава 4).
Эффект второй системы. Программист, разрабатывающий свою вторую систему, склонен добавлять все те возможности, которые он не смог добавить в свою первую систему (из-за нехватки времени). Поэтому вторая система часто получается перегруженной возможностями (глава 5).
См. также: Раздутое программное обеспечение
Формальные документы. Каждый менеджер проекта должен составить небольшой набор формальных документов, описывающих цели проекта, как, кем и когда они будут реализованы, и сколько они будут стоить. Эти документы могут вскрыть несоответствия, которые иначе было бы трудно заметить.
Каждая группа разработчиков получает набор требований к своей части системы, включая точное описание её функциональности и предельные требования к процессорному времени, занимаемой памяти, месту на диске и т. д.
Взаимодействие. Чтобы предотвратить катастрофу, группы разработчиков должны взаимодействовать друг с другом всеми возможными способами. Вместо того чтобы строить предположения по поводу реализуемой им функции, разработчик должен задавать архитектору уточняющие вопросы, поскольку предположения могут оказаться совершенно неверными. «Предположение — мать провала».
Пилотная система. Перед тем, как разрабатывать окончательную систему, необходимо разработать пилотную систему. Пилотная система выявит ошибки в проектировании, после чего она должна быть полностью переделана (глава 11). Эту идею Брукс отвергает через 20 лет в главе 19, так как за 20 лет изменился подход к созданию программ — на место принятой в 60-х—70-х каскадной модели разработки пришла итеративная.
Версии и замораживание системы. По мере создания системы, требования пользователя к ней могут меняться под влиянием его опыта работы с незаконченной системой. Эти пожелания пользователя следует учитывать, но только до какого-то момента, иначе работа над системой никогда не будет закончена. После этого спецификации замораживаются, и все последующие требования изменений откладываются до начала работы над следующей версией (глава 11).
Специализированные утилиты. Вместо того, чтобы каждый программист писал собственные утилиты, в каждой группе разработчиков должен быть один программист, ответственный за написание утилит для своей группы (например, генератор кода, создающий код в соответствии с какими-то спецификациями). Должна быть также группа, создающая утилиты для всех работающих над данной системой (глава 12).
Снижение стоимости разработки. Брукс приводит 2 способа снизить стоимость разработки программного обеспечения: