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