30 сентября 2010 в 4:05
Перерыл весь drupal.org/handbook, но так и не нашел документации по БД. Т. е. документацию по структуре базы данных, типу используемых данных, о том, что, где и для чего используется. Конечно, можно самому просмотреть все таблицы, но отсутствие некоего официального F.A.Q. удручает, плюс ко всему не всегда можно сходу понять предназначение той или иной таблицы или какого-то столбца. Почему-то не оставляет ощущение, что на drupal.org все это есть, но я просто не нашел=)
И еще такой момент волнует - сейчас установил себе Drupal 7 потестить, оказалось, что все таблицы по дефолту создаются типа InnoDB, однако не встретил ни одного использования внешних ключей. Если кто-нибудь следит за развитием семерки, то интересно, планируется ли вообще использование связанных таблиц?
Комментарии
Вы точно ИСКАЛИ? Даже на drupaler.ru есть
Ключи и цедостность конечно дело хорошее, но думаю, что касательно мускуля ценность не более академической
Да и вообще, столько граблей и гемороя выплывает, что нуивонах
Точно искал=) На drupaler.ru нашел, спасибо. А вот аналогичное описание на drupal.org в упор не вижу, уже и поиском по сайту пользовался, и гуглил - все в пустую
А можно чуток по-подробнее? Мускл раньше юзал только дилетантским образом, сейчас вот возникла надобность использования БД на уровне немного сложнее "Hello, world". Начитался умных книг и статей, сейчас прибываю в состоянии "нормализация, целостность и прочие блага MySQL - наше фсе", и тут меня опускают на землю "академической ценностью" всего этого)
Я, собственно, сразу и понял что это либо ВУЗ, либо книжки.
Проблемы тут такие:
1. API. Друпал работает не только с мускулем, что накладывает головняки. Тот же SQLite, не думаю что он поддерживает внешние ключи на должном уровне, хотя могу ошибаться + у каждой БД могут быть свои тараканы.
2. MyISAM стоящий у подавляющего большинства хостеров. Настолько я помню, там вообще просто поддержка внешних ключей для галочки, типа она есть, но пофиг что она есть.
3. Частичные бекапы БД, т.е бекапы одной таблицы. Вот смеху-то будет при восстановлении, когда другая таблица изменилась. А такая задача очень часто возникает.
4. Разработчики. Тут индексы не всегда проставляют в самописных модулях, а вы внешние ключи хотите.
Одновременно=) Собираюсь делать проектик один, а тут как раз лекции по БД начались, условно договорился с преподавателем забить на все лабы, а просто сдать свой проект в качестве курсача, но чтобы зачлось, надо не менее 5 связанных таблиц и вообще "правильное проектирование"=)
Буквально пару часов назад обнаружил, что у моего хостера на моем тарифе нет поддержки InnoDB, надо переходить на более дорогие тарифы.
За развернутый ответ, спасибо. Но все эти минусы касательно Друпала, который накладывает свои ограничения. А для более-менее сложного проекта "с нуля", все эти замуты с внешними ключами и прочим имеют смысл или тоже только в качестве академ. ценности?
Хотите нормальной работы с БД - подключайте Postgre, благо поддержка у Друпала есть.
А Мускул более чем на select, insert, update, drop и join использовать не стоит
По MySQL информации больше, книг, статей, форумов. Это для меня пока основополагающий фактор для выбора СУБД=) Да и MySQL по сути является "дефолтной" СУБД, LAMP на то и LAMP. Специфичных требований к БД пока не предъявляю, в основном в силу отсутствия необходимых знаний, чтобы эти самые требования можно было бы предъявить. А PostgreSQL многие советуют заместо MySQL, уже не первый раз замечаю, даже успел пережить один холивар "PostgreSQL vs MySQL"=)
Печально слышать=) Всегда думал, что MySQL удовлетворяет большинству запросов и является своего рода "правильной" СУБД, пусть без наворотов, но и без особых "косяков".
Это для меня было косвенным показателем состоятельности MySQL:
что-то типа "MySQL известна, стабильна, является эталоном" и т. д. в том же духе=)
Увы, будущее Мускла после покупки его Ораклом достаточно туманно.
Серьезно, если ваш проект будет использован в качестве курсача - берите Постгре, научитесь большему.
Да, на Мускл дофига информации. Но мне как разработчику всегда было достаточно одного файла - официальной документации в формате CHM. Для администратора, возможно, нужна другая информация.
Ээээ... Надо читать еще
Это вам в PostgreSQL.
Типа фича Drupal -- как и многих и многих CMS -- ровно в том и состоит, что API позволяет абстрагироваться от БД. Ну, в теории (на практике все равно приходится).
Но для "правильного проектирования" MySQL -- точно не та вещь, мускул -- это штука типа "быстро и как-то, но работает", специфично заточенная под Web-нагрузку вида "много простых селектов".
И чтобы там Oracle ни пыжилась, вряд ли за пределы этого уйдет.
Мускул -- специфичная СУБД для специальных задач. То, что одна из этих задач -- обслуживание Web -- сути дела не меняет. Но в своей нише -- она хорошая, даже отличная. Но в нише. Но хороша, как любой специальный инструмент.