|
|
|
| Вот прочитал, что права на InnoDB получил Оракул.
Теперь что, не рекомендуется его использовать в MySQL?
То есть, вот сейчас сижу и проектирую новую базу.
Какие таблицы мне использовать?
Намечается одна большая таблица.
Как с ней поступить? | |
|
|
|
|
|
|
|
для: Eugene77
(08.11.2007 в 17:52)
| | В любом случае сможете пользоваться старыми версиями InnoDB, а когда MySQL откажется от этого движка - просто сделаете SQL-дамп, замените тип таблицы и перейдёте на Falcon (когда он будет разработан), который MySQL AB разрабатывает в качестве замены InnoDB. | |
|
|
|
|
|
|
|
для: cheops
(08.11.2007 в 18:00)
| | Боюсь я этих всех дампов как чёрт ладана!
Мне кажется даже сама база по умолчанию
базируется на InnoDB.
Мне бы как-то это изменить и в итоге получить
программу, которую не затронут никакие шторма.
Есть у меня такая возможность? | |
|
|
|
|
|
|
|
для: Eugene77
(09.11.2007 в 15:46)
| | Если не используется каскадное обновление и удаление можно просто изменить тип таблиц с InnoDB на MyISAM при помощи запроса ALTER TABLE. | |
|
|
|
|
|
|
|
для: cheops
(09.11.2007 в 15:56)
| | А где почитать про
каскадное обновление и удаление | |
|
|
|
|
|
|
|
для: Eugene77
(09.11.2007 в 18:08)
| | Следует искать в мануале или в интернете информацию по ключевому слову Foreign Keys
- Внешние Ключи. | |
|
|
|
|
|
|
|
для: cheops
(09.11.2007 в 18:40)
| | А, если так, то примерно понятно.
Это видимо такое связывание таблиц, когда удаление
из одних приводит к удалению из других.
Даже читать не буду - мороз по коже!
Вы мне не подсажете как сделать чтобы база не основывалась на InnoDB?
Возможно это вообще?
И ещё, почему все так старательно обходят вниманием BDB?
Меж тем, другой таблицы, поддерживающей трансакции вроде нет.
Для большой таблицы что лучше применить? | |
|
|
|
|
|
|
|
для: Eugene77
(10.11.2007 в 18:49)
| | >Даже читать не буду - мороз по коже!
Разбирайтесь с понятиями ограничений, транзакций. В любом случаи без этого никуда. Современные промышленные СУБД без этого не обходятся, взять хоть Oracle, хоть условно-бесплатный FireBird. | |
|
|
|
|
|
|
|
для: oradev
(10.11.2007 в 19:18)
| | > условно-бесплатный FireBird
Хм.. а FireBird разве не свободная СУБД? | |
|
|
|
|
|
|
|
для: oradev
(10.11.2007 в 19:18)
| | >Разбирайтесь с понятиями ограничений, транзакций. В любом случаи без этого никуда. Современные промышленные СУБД без этого не обходятся, взять хоть Oracle, хоть условно-бесплатный FireBird.
Спасибо за неожиданный совет, только не могли бы вы чуть подробней?
Трансакции, если я правильно понимаю, это когда другим процессам не дают работать с таблицей, пока процесс инициировавший трансакцию не закончит свои дела.
Это да - полезно.
Что такое ограничения? О чём вообще речь? Есть ли они в Mysql?
Ну а касаясь удалений, то я стараюсь либо не удалять данные, либо складывать
потенциально устаревающие данные в такую таблицу , от которой уже ничего не зависит.
Пока получается.
Можно, кнонечно изобрести ситуацию где так невозможно сделать,
но в реальной жизни, мне кажется так и есть - никто не строит дом на песке.
Это программисты базы проектируют не совсем верно.
Не знаю понятно ли я высказался.
To Cheops:
Пока мне кажется, что таблица не уйдёт за пределы 1Г,
но наверняка сказать невозможно. | |
|
|
|
|
|
|
|
для: Eugene77
(11.11.2007 в 18:38)
| | >Что такое ограничения?
По сути речь идёт о триггерах в терминах SQL (В MySQL они называются также).
>Пока мне кажется, что таблица не уйдёт за пределы 1Г,
В этом случае MyISAM подойдёт, если таблица достигает 10 Гб, лучше думать в сторону InnoDB. | |
|
|
|
|
|
|
|
для: Eugene77
(11.11.2007 в 18:38)
| | Буду пояснять, Транзакция - это некий логическая единица работы. Она состоит из блока операторов SQL, в свою очередь результат выполнения этих блоков - или фиксация транзакции (последовательности операторов) или откат данных результатов. Совершенно верно вы заметили, действительно с момента начала транзакции происходит ее блокировка, транзакция заканчивается в момент либо ее фиксации либо ее отката.
Ограничения носят смысл целостности данных в таблицах. Некоторые ограничения наверняка вам знакомы: NOT NULL, Primary Key, Unique. Но кроме них есть еще такое ограничение как Foreign Key (внешний ключ) - который может принимать любое значение из множества PK или NULL. А в случаи нарушения данного ограничения вы немедленно получите исключение - таким образом СУБД сама берет на себя задачу по обеспечению целостности данных. | |
|
|
|
|
|
|
|
для: Eugene77
(10.11.2007 в 18:49)
| | >Вы мне не подсажете как сделать чтобы база не основывалась на InnoDB?
При создании таблицы при помощи оператора CREATE TABLE используйте параметр ENGINE
CREATE TABLE ... ENGINE=MyISAM;
|
>И ещё, почему все так старательно обходят вниманием BDB?
Она не в каждый дистрибутив MySQL входит по умолчанию - можно не найти на хостинге.
>Для большой таблицы что лучше применить?
Озвучте объём таблицы в мегабайтах. | |
|
|
|
|
|
|
|
для: cheops
(11.11.2007 в 13:10)
| | Да FireBird безусловно бесплатная СУБД. | |
|
|
|
|
|
|
|
для: Eugene77
(08.11.2007 в 17:52)
| | хм.... не доверяю я InnoDB после этого ...) | |
|
|
|
|
|
|
|
для: CrazyAngel
(14.11.2007 в 03:15)
| | Получается, что InnoDB ещё сыроватая таблица?
Впрочем, это как бы и не важно для меня в данный момент. Размеры позволяют мне обходиться
MyISAM, да и ладно.
Единственно, что нет уверенности, что действительно позволяют.
Несколько табличек у меня получаются очень склонных к фрагментации.
Размер - тоже порядка гигабайта, может, немного меньше. Дефрагментировать их надо
каждый час.Как это будет сказываться на функциональности сайта? Надолго он будет ложиться?
Вообще, это безопасно - давать запрос на дефрагментацию таблицы, когда к ней идёт и много других запросов?
Если это была бы InnoDB, я бы сделал трансакцию. А так как правильно? | |
|
|
|