- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Не могу не пожаловаться: у меня, после недели непрерывной работы таки почти скопытилась :) Журнал она, вишь ли, ведет... зафлудила inod...
А может, Oracle попробовать?
А версия какая? А настройки InndoDB? Макс. размер логов?
В 3.23.x большие таблицы InnoDB очень медленные. Попробуйте сделать какой-нибудь агрегат на таблице, скажем в 1 млн. записей.
В 4.x не знаю, еще не успел плотно опробовать.
Вообще mysql подходит для несложных вещей. А если необходимы надежные транзакции или, скажем, хотите непременно реализовать бизнес-логику на стороне СУБД, тогда mysql не подойдет однозначно. Тоже самое и со сложными структурами(например, которые сами себя поддерживают). Тот же nested sets при помощи хранимок и триггеров — сказка, а в mysql приходится всю логику на клиентской стороне реализовывать.
Мне в принципе нужно от СУБД в данном случае просто хранить данные(индекс) ввиде дерева.
p.s. Кто-нибудь знает, где можно получить sql for smarties(а лучше sql hierarchy structures) в электронном виде, там вроде Celko описывает различные деревья в sql-реализации.
А вообще реляционные СУБД в принципе не подходят для иерархических данных(ну может кроме нового SQL Server 2005, там вроде встроили поддержку средставми расширения стандарта ANSY SQL).
Смотрю в сторону Posgres. Там по-моему есть все, что нужно, и бесплатно:)
p.p.s. Почему же все-таки хочется SQL? Ответ прост: проще работать с данными, чем на c++(тут же по сути придеться писать свою мини субд, а хранилище будет файловая система).
А как вспомню, что нужно опять работать вручную с памятью, аж в дрожь бросает:))
Скажу возможно крамольную вещь, но все же:
Если у вас нет необходимости работать руками с памятью и указателями — не работайте, ибо машина скорее всего сделает это не хуже вас. За примерами ходить далеко не надо. CLR, JRE и т.д. Но уметь это и понимать как все это работало в прошлом веке вы обязаны:)
Sherman, Там, где нужно работать с памятью и указателями, не всем средам можно доверять (это не сама машина :), а всего лишь компиляторы и интерпретаторы). Утечки памяти и переполнения есть почти везде.
Версия MySQL - 4.1.11.
И мне кажется, что при сборке ее с либами gcc-3.4.2 порой возникают какие-то внутренние конфликты. Потому как этот компилятор более жесткий - он практически не признает warning'ов...
Настройки InnoDB варьировала по-разному. Насколько могу видеть, размеры логов в конфиге не превышают допустимого... буду еще разбираться. Проблем выше крыши и без этого...
Не уверена насчет хранимых процедур, а транзакции в пятой версии MySQL уже есть, как и все остальные прелести вроде триггеров и вложенных запросов.
Кстати, в треде про подбор СУБД мы поднимали тему, что для специфичной задачи, критичной по времени, требуется все-таки своя мини-СУБД.
Насчет с++, я имел ввиду под «машиной» именно среду, незря же привел примеры. Мне кажется человек может допустить ошибку даже чаще, чем автомат, т.к. эти области(манипуляции с указателями, например) весьма нетривиальны. В C# это и еще кое-что вообще убрали, и не только из-за несовместимости с CLR, а как раз потому что CLR гарантирует безопасную работу с памятью, а работа с указателями в ручную этого не гарантирует, хотя можно это использовать в блоках unsafe code.
mysql 5 еще долго будет оставаться alpha, beta, pre, rc, etc. Когда она будет stable известно наверное только одному Богу:)
У меня задача не настолько критичная, чтобы отказываться от SQL, как от языка работы с данными, реализовывать же его самостоятельно — не просто.
Sherman,
Да, чтоб отказаться от стандартной СУБД, надо иметь веские причины.
С другой стороны, иногда необязательно самостоятельно реализовывать весь SQL - достаточно знать, что именно необходимо.
Если уж речь зашла о c++, советую всё-же отказаться от mysql, и разработать свою БД. Алгоритмы все известные, а на писанину времени уйдёт не более чем, на поиски приручения mysql. Естественно плюсы - своё = что хочу то и ворочу + оптимизация под конкретную задачу.
Про СУБД речь не веду - зачем изобретать какой-то язык управления данными в БД, если управления толком то и не будет, сразу готовые процедуры оптимизированные и выполняющие конкретные действия.
Я уже высказывал свое мнение , mysql для задач индексации не годиться вообще . Mysql - заточен в два конца , на чтение и на вставку . При таком подходе в любом случае будут излишние накладные расходы на хранение данных , на их обработку . Разумно использовать mysql под коллекционирование данных. А выдачу для клиента оптимизировать с учетом одноразовой записи и многоразовой выдачи. Mysql удачен для длинних записей , не для организации деревьев.
alyak, А кэширование? Возможно, оно подойдет и при mysql, если разумно настроить кэш....
lagif, а файловая система куда как лучше кешировать будет.
Деревья в SQL. Часть 1.
Ты тему читал? Это и есть прототип nested sets. Но он тут не подойдет, т.к. слишком часто и по-многу будут проходить insert-ы. А в nested sets нужно каждый раз перестраивать дерево почти полностью, для вставки одной записи.
Nested Sets оптимально использовать для каталога. Выборка идет почти всегда одним запросом. И там где захлебнется parent-child, nested sets прекрасно будет себя чувствовать, единственные проблемы с сортировкой здесь. Но и их можно решить разными способами.