Мы с MSSQL соскочили еще 9 лет назад. На версии 6.5. Никто не спорит, для определенных не очень больших задач она хороша. Один недостаток - платформа MS, которая в свою очередь упирается с Intel архитектуру. 1С с парой сотней пользователей - очнень хороший пример. У меня перед глазами пара контор, которые пытаются выжать из Intel архитектуры макимум ( кроссовер с терминальными серврами, раздельные сервера для совершения действий и просмотра, изощренная система их синхронизации и.т.д. ) То, что они потратили за 2 последних года на поддержание работоспособности в 2 раза превышает стоимость начального сервера RISC архитектуры и ораклом или DB2. А решения по портированию нет :(
Да и 1С 7 и 8 версии абсолютно несовместимы.
Согласен. Правда, как и во всем, тут важно не переборщить. :)
У нас много интранет решений, где своя специфика... статические кэши - не всегда панацея.
При условии, что система не будет развиваться новым функционалом, и нет никаких требований к безопасности.
Приведу аналогию с перевозками:
Есть задача - развозить небольшой груз до 200 кг по городу - в этом случае Вам придется покупать Каблучок - дешево и сердито.
Объем груза увеличился - можно использовать 3 каблучка или 1 газель.( это уже другой класс).
Увеличилось расстояние - можно отправлять груз газелью, а можно и магистральным грузовиком, взяв до кучи еще груз.
если речь и дет о сотнях тонн, обычно используют железнодорожный транспорт, или в результате, смешанные перевозки. Т.е. Железная дорога - Магистральный тягач - Каблучок или газель. :)
Я никоем образом не агитирую делать сайты на 100 страничек на Oracle, хотя, думаю, что при наличии мощностей, их инструментария и лицензий - это будет недорого.
Я просто обращаю внимание, что формулировка "90 000 документов" очень расплывчата. Надо понять, что надо делать с этими документами, какая должна быть модель представления данных и модель безопасности. Какой объем в документах будет через год, а через 3 года? Какой планируется трафик?
Только ответив на эти и еще множество вопросов можно говорить о том, что может встать в основу этой информационной системы.
Удален повтор
Не угадали. Это OS390/OS400. Там в качестве ФС используется полноценная DB2 :)
Заумь конкретная, но когда в идеологию въезжаешь - то просто прешься :)
А какие СУБД у микрософт? Недоросль MS SQL? ДыБы-МуДыБы всуе не упоминайте... она даже как таблица не очень :)
А это разные счета и никого это не волнует.
максимум, что Вы сможете сделать - снизить последующие платежи на размер снятой суммы, и то по согласованию с налоговой.
Итак, смотрим, какие должностные обязанности у кандидата:
1.
PR-менеджер.
2.
Копирайтер, Tech-writer, редактор, автор. Вообще-то я думал, что системы видеонаблюдения разрабатываются с документацией, т.е. технический писатель есть в штате.
3.
Верстальщик
4.
Дизайнер
5.
SEO специалист, линк-менеджер.
6.
Программист
7.
Системный администратор (полставки, если сайт на хостинге )
8. Самый загадочный пункт:
С одной стороны, если чел работает на компьютере(файловая система) или ищет в гугле и яндексе - он уже работает с базами данных.
С другой стороны - можно неделю писать один SELECT для хитрой выборки из 1C или RS-Banк... и это тоже работа с базой данных.
Но, скорее всего, хотят просто интегрировать прайс и склад из внутренней системы на каком-нибудь FoxPro c Web сайтом в реальном времени.
Короче, надо работать за семерых, а получать за одного... :)
Кстати, в районе Бауманки/Красносёлки я ни одного нормального ресторанчика не нашел, хотя бываю там довольно регулярно.
С другой стороны, обмаываем только самих себя :(
Я тоже не говорил, что контент протухает. Протухает кэш.
Просто нельзя создать универсальный механизм кеширования для каждой конкретной структуры данных. :)
Более того, файловая система - это тоже база данных. А еще есть операционные системы у которых в качестве файловой системы используется мощнейшая реляционная СУБД :)
ПОвторил в личку.
Не забывайте, что у Вас, кроме страниц с контентом, есть еще и индексные страницы. И кешировать, в первую очередь, надо именно их. Страница с контентом отдается достаточно быстро, поскольку там идет запрос к записи к контентом и к кешированным записям с обвязкой. А при запросе к индексной странице происходит обращение ко всей базе данных.
А как система кэшировния определит, что одна из записей индексной страницы была изменена?
А если масштабы работы чуточку выше, чем есть в реальности, то запросы просто игнорируются 😂
А может даже лучше, ибо с движками у Лебедева не ахти. :(
