Владимир Коротенко, вы же хотели конкретики? Вот вам конкретика - работающие не первый год системы, в которых ваши якобы обязательные Windows никому в хрен не уперлись.
Кстати, посреднику, который среди прочих заказов привел ко мне тех мебельщиков, очень удобно зайти на свой сайт, заполнить небольшую форму - и получить на нем поддомен с полностью рабочей копией той или другой CRM (с демо-данными, разумеется), в которой другой потенциальный заказчик может все пощупать и убедиться, годится ему такая система или нет. Без бодрых рассказов продаванов. И более-менее определиться, как он видит допиливание ее под себя. Предметно.
Владимир Коротенко, вы таки будете смеяться, но и для дизайнеров, и для мебельщиков я писал и внедрял самописные CRM-ки в одно лицо. Они ими пользуются до сих пор, вполне успешно, инструмент зашел и помогает. Кладовщики, в частности, радуются, что им не нужно бегать к компьютеру или таскать с собой ноут, все на смартфоне. Менеджеры, обеспечивающие тех дизайнеров работой, тоже легко считают заказ "на коленке" прямо у клиента.
Ни одна M$-технология в проектах не использовалась, банальный веб-стек на LAMP.
Владимир Коротенко, а я и не обвинял вас в теоретизировании. Но посмотрите на вопрос.
10 юзеров в локалке работают над заказами. Не УФМС-ы, таможни и прочий энтерпрайз, а автоматизация работы малого офиса. В которой нагромождения дотНета на хрен не нужны, а его же требования и ограничения - гиря на ноге без всякой на то причины.
Насколько я помню, сжимаются даже не файлы, а пакеты при передаче.
Так что бояться, что rsync сначала создаст здоровенный архив, а потом уже будет его пересылать - не стоит.
Владимир Коротенко, не будет. Лично мне совершенно очевидно, что ваши "пункты" высосаны из пальца, и продуцировать такое же бессмысленно. Ваши доводы не изменят моего опыта написания CRM на веб-стеке и переписывания на тот же стек изначально вымученных для десктопа программ. Я, в свою очередь, вряд ли смогу преодолеть вашу привычку смотреть на все задачи через дотНет.
Владимир Коротенко, или вы просто пользуетесь тем, что умеете, и нагибаете под него даже те задачи, для решения которых применение именно этого инструмента слабо обосновано, а то и противопоказано. Точно так же, как выше отписавшийся 1С-ник.
Не проще отправить SVG на бэк и там скормить ImageMagick, чем шаманить на фронте, ловя проблемы отрисовки в неизвестном браузере на неизвестном разрешении?
Владимир Коротенко, я не сомневаюсь, что ровно такой же список в обратную сторону вы напишете с той же легкостью, банально исправив "ущербный" на "универсальный", например ;)
Не будем увеличивать энтропию.
Владимир Коротенко, и миллионы мух, да-да.
БД все равно нужна, так что сервер для размещения бэкенда уже есть. Писать отдельный клиент для клиент-серверной системы, когда браузер все равно стоит на компьютере, а интерфейс заведомо шаблонен, да еще и имеет тенденцию к постоянным изменениям - пустая трата ресурсов сначала на написание, а потом на поддержку. Не говоря уже об упомянутых ТС архаизмах типа "выгонять всех из программы при обновлении справочников".
freeExec, ага, причем тот, кому надо, чтобы "еще вчера", и тот, кто допустил ошибки планирования, из-за которых все в жопе и конь не валялся - одно и то же лицо.
Собственно, и сама постановка задачи с условием "уже вчера" суть классическая ошибка планирования.
Akina, согласен с уточнением: перебор может использоваться компьютером - для эмуляции человеческих методов решения, напрямую компьютеру недоступных. Либо для реализации "человеческого" перебора, ограниченного объемом данных, которые нужно удерживать в быстрой памяти.
Akina, тут есть еще один практический нюанс: головоломки, для решения которых компьютеру придется запускать перебор, просто никому на хрен не нужны, поскольку человек с этим не справится, а головоломка - это таки для человека, а не какая-то математическая абстракция.
Поэтому "правильность" головоломок обычно дополнительно ограничена человеко-решаемостью.
А то и вовсе - обывателе-решаемостью, без слишком сложных техник ;)
mk11, по сравнению с чем? Решение судоку совершенно тривиально для компьютера, проверка занимает миллисекунды, и даже 81 такая проверка занимает меньше секунды - судоку, с точки зрения человека-наблюдателя, составляется "моментально".
А когда вдобавок окажется, что все те поля "клиники", над которыми так тужится ТС, нужны строго в одном месте без каких-либо перспектив поиска по ним и прочей обработки, не считая создания-правки-вывода - получится, что и хранить их можно совершенно как угодно, не насилуя для этого таблицы пользователей, например.
junart, через модель юзера - проще, но не удобнее. Раздутая без необходимости модель - это неудобно.
Распишите использование этой информации, это поможет понять, как ее надо будет читать и искать. Как хранить - решается в последнюю очередь, после этого понимания.
