Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
— Какая СУБД лучше всего подходит для хранения больших объемов информации, в районе 10 млн. ячеек и более. MySQL? Oracle?!
В принципе, любая известная. Я приверженец Oracle, но и MySQL все переварит. Хотя Oracle на один процессор стоит копейки, а можно поставить XE, он, правда, работает с ограничением 4 гига на базу, но это явно больше, чем 10 млн ваших записей.
Остальное не знаю, с Drupal не знаком.
В принципе, любая известная. Я приверженец Oracle, но и MySQL все переварит. Хотя Oracle на один процессор стоит копейки, а можно поставить XE, он, правда, работает с ограничением 4 гига на базу, но это явно больше, чем 10 млн ваших записей.
Остальное не знаю, с Drupal не знаком.
Oracle это сервер? А оболочка какая к нему?
Это СУБД
Это сервер базы данных, тыц.
«Оболочку» вам самим придется писать. Drupal в ваших терминах как бы средство создания «оболочки».
«Оболочку» вам самим придется писать. Drupal в ваших терминах как бы средство создания «оболочки».
Странно, что в фирме занимающейся СЕО нет человека, разбирающегося в таких базовых веб технологиях (или он есть, но пинает валенки). Вам явно нужно нанять одного но очень толкового и постоянного веб разработчика со знанием БД и приложений для хранения\общей обработки данных, либо отдавать это на аутсорс. ИМХО.
Наймите хорошего программера который вам без любой CMS сделает веб-аппликуху, точно отвечающую вашим нуждам. Если требования бизнес логики будут меняться не часто — то и содержать его на постоянной основе не надо будет — разовый заказ и оплата выполненых работ. Выложите это все на VDS и пользуйтесь на здоровье.
+1, только ищите человека/команду, который вместе с вами сядет и вникнет в бизнес-процессы. И вместе с ним составите ТЗ.
Решение в виде бд/веб-морды будет так же обладать недостатком онлайн-зависимости, однако, в отличие от «коробочных» продуктов или готовых SAAS (если только вам дико не повезет), позволит автоматизировать по вашим правилам рутинные задачи типа классификации и устранения дубликатов.
Главную проблему в нем вижу, что вероятно будет непросто придумать такой интерфейс, который был бы достаточно быстр (не грузить все данные в браузер) и при этом удобен для ваших нужд.
Решение в виде бд/веб-морды будет так же обладать недостатком онлайн-зависимости, однако, в отличие от «коробочных» продуктов или готовых SAAS (если только вам дико не повезет), позволит автоматизировать по вашим правилам рутинные задачи типа классификации и устранения дубликатов.
Главную проблему в нем вижу, что вероятно будет непросто придумать такой интерфейс, который был бы достаточно быстр (не грузить все данные в браузер) и при этом удобен для ваших нужд.
«веб-аппликуху» все-равно придется делать отдельно, а на ЦМС (если использовать) оставить вторичные функции, типа авторизации, разграничения прав, хранения справочной информации, етц.
Типа get.adobe.com/ru/air/?
коммент не понят. отдельно от чего использовать? я наоборот не призывал завязываться на друпал, а вообще отказаться от ЦМС так как и нее абсолютно другие функции
Надо было ещё раньше переходить на базы данных. Не вижу ничего с чем бы MySQL не справился, а он более популяер и проще использовать чем Oracle.
Если нужно только обрабатывать данные в этой базе (поиск, добавление, изменение), то PHP+MySQL считаю оптимальным вариантом.
Далее нужно создать фронтенд для неё или использовать готовые/универсальные, по ним только не подскажу, ничего кроме phpMyAdmin не использовал из универсального.
Создать же должно быть не сложно, операций не так много необходимо совершать.
Если нужно только обрабатывать данные в этой базе (поиск, добавление, изменение), то PHP+MySQL считаю оптимальным вариантом.
Далее нужно создать фронтенд для неё или использовать готовые/универсальные, по ним только не подскажу, ничего кроме phpMyAdmin не использовал из универсального.
Создать же должно быть не сложно, операций не так много необходимо совершать.
Что мешает взять MS SQL и склепать к нему простенький гуй на вижуал бейсике? Это мало чем отличается от того, чему учат на первом курсе любого ВУЗа, показывая, как работать в Access-е.
Ничего кроме совести и здравого смысла.
У них распределеная команда, веб будет лучше.
как вариант кстати можно сделать следующее:
1. У хостера или на своих мощностях развернуть MySQL/Postgres/etc
2. Установить openoffice base
Можно формочки порисовать, а можно и не порисовать. Дело вкуса.
1. У хостера или на своих мощностях развернуть MySQL/Postgres/etc
2. Установить openoffice base
Можно формочки порисовать, а можно и не порисовать. Дело вкуса.
Конечно сложно оценить характер вносимых вами данных по той информации, которую вы предоставили, но я также поддержу ораторов выше, которые советуют вам написать web-морду к MySQL базе данных. При написании web-морды можно использовать ExtJS. Получается доволно красиво при минимальных затратах по времени.
Вам, на мой взгляд не нужно думать ни о бэкенде в виде конкретной базы, ни о фронеде. Вам нужно скорее подготовить набор синтетически (или реальных есть есть возможность) данный наиболее близких к тому с чем вы работаете и описать набор тестов. Размер должен быть 2-3 кратный от текущего и второй набор 10-ти кратный.
Далее, описать набор реальных действий и описать для них скорость выполнения — от оптимальной до приемлемость.
Озвученные цифры не выглядят большими. 10 миллионов записей это мало. Даже если каждая запись это десятки килобайт текста. Вопрос скорее в том насколько вам нужно быстрое выполнения сложных действий — секунды, десятки секунд, минуты и т.п.
Подготовите данные, опишите тесты, напишите общее ТЗ — а потом просто отдайте исполнителю и он уже на основе этого сделает техническое ТЗ с учетом требований. Сделайте оценку технического ТЗ на предмет поддержки в будущем и дальше уже реализация.
Далее, описать набор реальных действий и описать для них скорость выполнения — от оптимальной до приемлемость.
Озвученные цифры не выглядят большими. 10 миллионов записей это мало. Даже если каждая запись это десятки килобайт текста. Вопрос скорее в том насколько вам нужно быстрое выполнения сложных действий — секунды, десятки секунд, минуты и т.п.
Подготовите данные, опишите тесты, напишите общее ТЗ — а потом просто отдайте исполнителю и он уже на основе этого сделает техническое ТЗ с учетом требований. Сделайте оценку технического ТЗ на предмет поддержки в будущем и дальше уже реализация.
Кстати можно вполне сделать десктоп приложение для ваших нужд, будет лучше работать с обработкой данных чем веб приложение. Написать на чём наёмному программисту будет легче: Java/C#/C++.
Наш удаленный офис состоит из 30 человек. Работа связана исключительно с SEO под США. А это предполагает, что денно и нощно — так как работники разбросаны по разным временным поясам — мы ищем и находим сотни ссылок...
Какие-то проблемы с подключением к удаленной базе данных?
MySQL крутится себе спокойно где-нибудь на сервере. Клиенты подключаются к нему удалённо.
Так же как это можно сделать из консоли:
MySQL крутится себе спокойно где-нибудь на сервере. Клиенты подключаются к нему удалённо.
Так же как это можно сделать из консоли:
mysql -h remote_host
Да нет, технических проблем связаться с базой нет, но в этом случае они получат проблему сопровождения десктопного приложения в офисе, раскиданном по всему миру. Это точно, чего они не хотят.
Не вижу ничего страшного. Если написать на Java, то приложение получится достаточно хорошо абстрагированным от хоста. Функционала не так много, даже студент справится. А если и возникнут какие-то проблемы, то 30 человек это не так много, можно с каждым индивиуально их обсудить и устранить баги.
С веб приложениями тоже не всё гладко.
Везде свои плюсы и минусы.
С веб приложениями тоже не всё гладко.
Везде свои плюсы и минусы.
Я с клиент-серверной технологией поработал достаточно и я вижу.
Во-первых, поддержание работоспособности сервера, над которым у админа полный контроль и десятков пользовательских компьютеров — две очень больших разницы. Даже апдейт выкатить — не фунт изюму.
Во-вторых, их сегодня 30, а завтра будет 300 и приложение усложниться в десять раз. Оно мне надо?
Нет, по-моему веб однозначно.
Во-первых, поддержание работоспособности сервера, над которым у админа полный контроль и десятков пользовательских компьютеров — две очень больших разницы. Даже апдейт выкатить — не фунт изюму.
Во-вторых, их сегодня 30, а завтра будет 300 и приложение усложниться в десять раз. Оно мне надо?
Нет, по-моему веб однозначно.
Не понятно, почему связка сервер+десктоп приложения при увеличении количество рабочих копий десктоп приложение последнее должно усложниться? На мой взгляд оно даже не обязанно измениться — какая разница сколько копий запушено (с точностью до количество пользователей у веб морды).
Потому что у фирмы в 300 человек бизнес-правила в 10 раз сложнее, чем у фирмы в 30 человек.
— какая разница
Разница очень большая. В вебе нужно обеспечить работоспособность одного сервера. В клиент-сервере — сеть изо всех компьютеров.
Спросите у ближайшего админа — согласен ли он поддерживать работоспособность сети (т.е. запускаемых на компе программ), где каждый имеет на свой комп админские права и может установить и сконфигурировать любой софт. Я уверен, что он пошлет вас далеко: либо он все контролирует, либо ни за что не отвечает.
— какая разница
Разница очень большая. В вебе нужно обеспечить работоспособность одного сервера. В клиент-сервере — сеть изо всех компьютеров.
Спросите у ближайшего админа — согласен ли он поддерживать работоспособность сети (т.е. запускаемых на компе программ), где каждый имеет на свой комп админские права и может установить и сконфигурировать любой софт. Я уверен, что он пошлет вас далеко: либо он все контролирует, либо ни за что не отвечает.
При соответствующем подходе, клиентское приложение ничем не отличается от браузера.
И сложность проблем с ним не сложнее чем морока с браузерами и прочим.
Если мы уж говорим о достаточно низко квалифицированных сотрудниках (хотя помоему не тот случай), то проблем с браузерами может быть даже больше.
Впрочем, опять же я не спорю что затраты на развертывание больше. Просто не все так страшно. И опять же нивилируеться плюшками в UI.
Все таки не даром мобильные версии Excel все же не доросли до оригинала еще.
И сложность проблем с ним не сложнее чем морока с браузерами и прочим.
Если мы уж говорим о достаточно низко квалифицированных сотрудниках (хотя помоему не тот случай), то проблем с браузерами может быть даже больше.
Впрочем, опять же я не спорю что затраты на развертывание больше. Просто не все так страшно. И опять же нивилируеться плюшками в UI.
Все таки не даром мобильные версии Excel все же не доросли до оригинала еще.
Я уже почти 10 лет работаю в С.Америке(10+ компаний) и не видел ни одной разрабатываемой дестопной корпоративной системы даже для интранета. Зато несколько раз учавствовал в переписывании дектопной под веб. И это при условии, что внутренние сети жестко администрированы. Но манагеры просто считают деньги. Плюшки? Аждакс, Flex, Silberlight, Flash и т.д. и т.п.
Лично я, будучи директором конторы и имея опыт, который у меня есть, однозначно за веб, про десктопы даже страшно думать. А уж в маленькой фирме, которая не в состоянии держать хелпдеск и техсаппорт и подавно.
Лично я, будучи директором конторы и имея опыт, который у меня есть, однозначно за веб, про десктопы даже страшно думать. А уж в маленькой фирме, которая не в состоянии держать хелпдеск и техсаппорт и подавно.
Я кстати частично поддерживаю.
Собственно серверная часть в любом случае должна быть единой. Что для веб-приложения, что для десктоп.
А написать базовую функциональность клиента в виде десктопного приложения достаточно просто.
Нужно просто посмотреть что нужно с клиентской части.
И возможно что будет проще опробовать эти решение в виде десктоп приложения — ибо тут подходов к UI позволяющих комфортно работать с большими данными исторический больше.
А потом переносить все уже чисто в веб.
Вопрос в ресурсах сугубо. Если стоимость относительно выгоды не очень велика, я бы подумал о двух вариантах — десктоп и веб морда. А серверу пофиг что обсуживать.
Собственно серверная часть в любом случае должна быть единой. Что для веб-приложения, что для десктоп.
А написать базовую функциональность клиента в виде десктопного приложения достаточно просто.
Нужно просто посмотреть что нужно с клиентской части.
И возможно что будет проще опробовать эти решение в виде десктоп приложения — ибо тут подходов к UI позволяющих комфортно работать с большими данными исторический больше.
А потом переносить все уже чисто в веб.
Вопрос в ресурсах сугубо. Если стоимость относительно выгоды не очень велика, я бы подумал о двух вариантах — десктоп и веб морда. А серверу пофиг что обсуживать.
Ну, мы могли бы вам сделать мини-ERP систему, за небольшие деньги
.NET + mssql + webморда
.NET + mssql + webморда
Но в чем проблема? SQL в виде базы данных не откроешь в Блокноте, не станешь редактировать вручную.
Почему нельзя использовать phpmyadmin например? Может быть для добавления данных она недостаточно удобна, но функции поиска и редактирования выполняет вполне неплохо
Да, представьте себе 30 человек разного уровня технической подкованности, работающих в PMA одновременно. Особенно девушки, которые только завербовались :)
Можно настроить тип материала в который добавить составное поле (первое что нашел в поиске, думаю что есть много подобного), включающее в себя нужные вам поля
И для каждого сайта (или как вы группируете?) создавть ноду этого типа.
PS: Первое, что пришло в голову, пока читал статью, и не дошел еще до упоминания о друпал :)
ps1: Сразу оговорюсь — не знаю как будет работать с большими объемами.
ps2: Придеться писать какой-то импортер из екселя в друпал, ибо в базе хранится не так тривиально, как в екселе. Т.е. средствами sql имортировать вероятно не получиться. Надо будет использовать Drupal API для добавления нод и т.п.
дата, URL, comment и т. д, сделать возможность добавить неограниченного количества этих полей.
И для каждого сайта (или как вы группируете?) создавть ноду этого типа.
PS: Первое, что пришло в голову, пока читал статью, и не дошел еще до упоминания о друпал :)
ps1: Сразу оговорюсь — не знаю как будет работать с большими объемами.
ps2: Придеться писать какой-то импортер из екселя в друпал, ибо в базе хранится не так тривиально, как в екселе. Т.е. средствами sql имортировать вероятно не получиться. Надо будет использовать Drupal API для добавления нод и т.п.
> Какая СУБД лучше всего подходит для хранения больших объемов информации, в районе 10 млн. ячеек и более. MySQL? Oracle?!
На таком объеме — любая.
Я лично предпочитаю постгрес, но не навязываю
> Управление БД посредством Drupal — насколько оно эффективно?
Не эффективно, потому что Drupal — CMS созданная для других задач. Сам часто юзаю друпал. но здесь он не к месту.
> Какие решения, помимо баз данных, можно использовать в сравнительно небольшой компании?
Не вижу смысла в других решениях. По вашему тексту впечателние, что у вас вся работа идет с таблицами — значит вам и надо взять хорошую реляционную БД и сделать там таблицы.
> Есть ли смысл содержать программиста Drupal на постоянной основе? Поначалу можем переместить только часть данных в SQL, а что-то хранить в GDocs, например, отчеты.
Нет.
Возьмите лучше Django — на ней можно очень быстро и удобно сделать то, что вам нужно. Потратьте 2 вечера и получите очень удобный инструмент. При этом у вас очень эффективно будет использоваться база.
На таком объеме — любая.
Я лично предпочитаю постгрес, но не навязываю
> Управление БД посредством Drupal — насколько оно эффективно?
Не эффективно, потому что Drupal — CMS созданная для других задач. Сам часто юзаю друпал. но здесь он не к месту.
> Какие решения, помимо баз данных, можно использовать в сравнительно небольшой компании?
Не вижу смысла в других решениях. По вашему тексту впечателние, что у вас вся работа идет с таблицами — значит вам и надо взять хорошую реляционную БД и сделать там таблицы.
> Есть ли смысл содержать программиста Drupal на постоянной основе? Поначалу можем переместить только часть данных в SQL, а что-то хранить в GDocs, например, отчеты.
Нет.
Возьмите лучше Django — на ней можно очень быстро и удобно сделать то, что вам нужно. Потратьте 2 вечера и получите очень удобный инструмент. При этом у вас очень эффективно будет использоваться база.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Формат хранения данных для совместного доступа в облаке