Если вы не видите смысла, это не значит что его нет
1) экономия дискового места, - не приходится дублировать одну и ту же информацию
2) удобство в случае необходимости переноса файлов из одного каталога в другой.
2.1) удобство в случае миграции всего файл сервера.
Если постараться, можно придумать еще несколько потенциальных сценариев.
Сергей имел ввиду, что бекап, который невозможно развернуть и сделать систему вновь доступной, равнозначен отсутствию бекапа. Тоесть ваши затраты на организацию инфраструктуры бекапов и их созданиия, это деньги на ветер. Что впоследствии с 99% вероятностью принесет гораздо больше убытков, чем если бы вы организовали регулярное тестирование бекапов.
Вручную тестрировать разворачивание бекапов никто не предлагает. Для этого есть масса инструментария, начиная с powershell. Задача админа или программиста, - написать толковый скрипт, который сможет автоматически развернуть систему на тестовой машине, и потом попросить юзера выполнить несколько ручных действий на развернутой системе - сгенерировать какие-то отчеты, создать контрагента или какую нибудь проводку. Делать это будет достаточно раз в месяц, при чем ручной работы пользователя там будет всего на 30 минут. Скрипт разворачивания пусть после окончания отправляет письмо пользователю, с просьбой проверить работоспособность развернутого бекапа. В качестве отчета, пользователь может отправить вам по почте несколько скриншотов.
Посмотрел на Inventor, - у него хороший набор уже готовых параметризированных элементов для редуктора: валы, шестерни, подшипники и тд. Можно достаточно быстро набросать некий механизм, практически не прибегая к рисованию в 2d. https://www.youtube.com/watch?v=sqUYtB3Rbl8
Спасибо, про параметризацию созданной модели я в курсе, но речь не о ней.
Необходим инструмент, который сможет сам предложить модель сопряжения, либо сгенерировав её по некоему интеллектуальному алгоритму, либо имея большую базу данных параметризированных сопряжений.
У многих это скольки? Судя по статистике с expandedramblings.com/index.php/march-2013-by-the-...
"Average Number of Followers per Twitter User:208"
"Average number of followers that teens on Twitter have:79"
Когда дорастёте до твиттера, то и решения станете использовать соответствующие.
Огромный - понятие относительное. Вы уже сами написали "одних айдишек будет мегабайт 16". Допустим, у вас будет ограничение как в фейсбуке на 500 френдов для одного пользователя, что в максимуме даст 500*16 + 16. Несчастных 8 гигабайт оперативы, при самом объемном сценарии. При этом стоит учитывать, что у среднестатистического пользователя в среднем до пары сотен подписок.
filepath я бы вынес в отдельную таблицу поскольку:
а) при большом количестве файлов будет расходоваться много лишнего места на данные и возможный индекс по этому полю
б) при потенциальной миграции большой группы файлов между каталогами, усложнится выполнение запроса.
Для крупносерийного производства, в промышленных масштабах литье выйдет дешевле по себестоимости. Поэтому конкурировать с отливками будет сложно.
Вам возможно стоит больше сфокусироваться на создании своей партнерской сети частных стоматологических кабинетов в своем регионе, смогут загрузить ваш станок достаточным количеством заказов.