собстно есть таблица:
CREATE TABLE `cat_list` (
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE ,
`p_note` VARCHAR( 50 ) NOT NULL PRIMARY KEY ,
`p_obj` VARCHAR( 255 ) NOT NULL ,
`p_number` VARCHAR( 255 ) NOT NULL ,
`p_desc` VARCHAR( 255 ) NOT NULL
) TYPE = MYISAM CHARACTER SET cp1251 COLLATE cp1251_general_cs;
и данные:
INSERT INTO cat_list (p_note, p_obj, p_number, p_desc) VALUES ('API001', 'Bull 11L4: 1970 API Bulletin Containing Curves for Selecting Beam Pumping Units', 'Bull 11L4', 'API Bulletin Containing Curves for Selecting Beam Pumping Units');
INSERT INTO cat_list (p_note, p_obj, p_number, p_desc) VALUES ('API001', 'Composite List of Manufacturers Licensed for Use of the API Monogram On Products Manufactured to API Exploration and Production Department Specifications', '', 'Composite List of Manufacturers Licensed for Use of the API Monogram on Products Manufactured to API Production Department Specifications, October 1, 1996');
INSERT INTO cat_list (p_note, p_obj, p_number, p_desc) VALUES ('API001', 'RP 5C5: 1996 Recommended Practice for Evaluation Procedures for Casing and Tubing Connections', 'Rp 5C5', 'Recommended Practice for Evaluation Procedures for Casing and Tubing Connections');
когда делаю импорт в mysql естественно идет ругня на колонку p_note где идут одинаковые значения. к тому же 100 строк идут с API001, потом следующие 100 уже с API002 и т.д.
как "избавиться" от ошибки чтобы не переделывать базу?
1. Viper - 23 Февраля, 2007 - 10:33:21 - перейти к сообщению
2. evgenijj - 23 Февраля, 2007 - 10:45:33 - перейти к сообщению
Отредактируй cat_list. Удали первичный ключ:
ALTER TABLE `cat_list` DROP PRIMARY KEY
Это можно сделать через phpmyadmin
Вообще, эта таблица какая-то странная:
ALTER TABLE `cat_list` DROP PRIMARY KEY
Это можно сделать через phpmyadmin
Вообще, эта таблица какая-то странная:
Цитата:
Первичные ключи являются одним из основных видов ограничений в базе данных. Они применяются для однозначной идентификации записей в таблице. Допустим, мы храним в базе данных список людей. Вполне вероятно, что могут появиться два (или больше) человека с одинаковыми фамилией, именем и отчеством Как же гарантированно отличить одного человека от другого (конечно. речь идет о том, чтобы отличить одного человека от другого на основании информации, хранящейся в базе данных)?
В данном случае "человек" представлен одной записью в таблице, поэтому можно задаться более общим вопросом — как отличить одну запись в (любой) таблице от другой записи в этой же таблице. Для этого используются ограничения - первичные кпочи. Первичный ключ представляет собой одно или несколько полей в таблице, сочетание которых уникально для каждой записи. Для одной таблицы не существует повторяющихся значений первичного ключа.
Уникальные кчочи несут аналогичную нагрузку - они также служат для однозначной идентификации записей в таблице. Отличие первичных ключей от уникальных состоит в том, что первичный ключ может быть в таблице только один, а уникатьных ключей - несколько.
Первичные ключи являются одним из основных видов ограничений в базе данных. Они применяются для однозначной идентификации записей в таблице. Допустим, мы храним в базе данных список людей. Вполне вероятно, что могут появиться два (или больше) человека с одинаковыми фамилией, именем и отчеством Как же гарантированно отличить одного человека от другого (конечно. речь идет о том, чтобы отличить одного человека от другого на основании информации, хранящейся в базе данных)?
В данном случае "человек" представлен одной записью в таблице, поэтому можно задаться более общим вопросом — как отличить одну запись в (любой) таблице от другой записи в этой же таблице. Для этого используются ограничения - первичные кпочи. Первичный ключ представляет собой одно или несколько полей в таблице, сочетание которых уникально для каждой записи. Для одной таблицы не существует повторяющихся значений первичного ключа.
Уникальные кчочи несут аналогичную нагрузку - они также служат для однозначной идентификации записей в таблице. Отличие первичных ключей от уникальных состоит в том, что первичный ключ может быть в таблице только один, а уникатьных ключей - несколько.
3. Viper - 23 Февраля, 2007 - 11:49:35 - перейти к сообщению
спасибо помогло 
а теперь ещё вопрос. есть таблица с 26,5 тыс. строк. Не будет ли тормозить mysql при работе с этой таблицей и есть ли варианты оптимизации в этом случае ?
а теперь ещё вопрос. есть таблица с 26,5 тыс. строк. Не будет ли тормозить mysql при работе с этой таблицей и есть ли варианты оптимизации в этом случае ?
4. evgenijj - 23 Февраля, 2007 - 12:18:32 - перейти к сообщению
Viper пишет:
а теперь ещё вопрос. есть таблица с 26,5 тыс. строк. Не будет ли тормозить mysql при работе с этой таблицей и есть ли варианты оптимизации в этом случае ?
а теперь ещё вопрос. есть таблица с 26,5 тыс. строк. Не будет ли тормозить mysql при работе с этой таблицей и есть ли варианты оптимизации в этом случае ?
Не знаю. Мои знания БД оставляют желать много лучшего. Попробуй спросить на http://sql[dot]ru
5. -SCHATTEN- - 25 Февраля, 2007 - 06:03:43 - перейти к сообщению
Гдето читал что при большом количестве строк MySQL немного притормаживает, лучше разбей её на несколько таблиц.
6. valenok - 25 Февраля, 2007 - 06:25:14 - перейти к сообщению
Зависит от типа таблиц (MyISAM, INODB)
С очень большим колвом данных отлично справляется Oracle
С ещё большим колвом данных лучше бд не использовать.
С очень большим колвом данных отлично справляется Oracle
С ещё большим колвом данных лучше бд не использовать.
7. Viper - 26 Февраля, 2007 - 09:45:17 - перейти к сообщению
спасибо за советы !
тип таблицы MYISAM
при таком количестве данных время генерации страницы составляет около 4 секунд. это с ограничением на вывод в 50 строк.
дамс тяжеловато
тип таблицы MYISAM
при таком количестве данных время генерации страницы составляет около 4 секунд. это с ограничением на вывод в 50 строк.
дамс тяжеловато
8. -SCHATTEN- - 26 Февраля, 2007 - 11:13:40 - перейти к сообщению
Ну вот сам и сделал выводы =)
9. Viper - 26 Февраля, 2007 - 14:48:46 - перейти к сообщению
собстно ещё поправил запрос было SELECT *
указал названия столбцов и время сократилось до 0,5 секунд
указал названия столбцов и время сократилось до 0,5 секунд
10. -SCHATTEN- - 26 Февраля, 2007 - 15:13:15 - перейти к сообщению
Вообще MySQL считается одной из самых быстрых БД. В ней упор поставлен на быстродействие, но для достижения этой цели в ней не полностью реализован SQL в ней отсутствует транзикации, которые замедлили бы её работу. Кроме этого она плохо работает с большим количеством информации.
Так что MySQL врят ли подойдет в качастве БД в твоем случае.
Так что MySQL врят ли подойдет в качастве БД в твоем случае.
11. evgenijj - 07 Марта, 2007 - 09:35:56 - перейти к сообщению
Viper пишет:
собстно ещё поправил запрос было SELECT *
указал названия столбцов и время сократилось до 0,5 секунд
указал названия столбцов и время сократилось до 0,5 секунд
Совершенно случайно сегодня наткнулся в журнале LINUX FORMAT за ноябрь 2005 г.
Цитата:
При работе с MySQL ... старайтесь избегать использования шаблона (*) в операторе select (например, select * from mytable). Это кажется очень удобным, но запрос будет выполняться намного медленнее и создавать дополнительный сетевой трафик. Вместо этого указывайте только те поля, которые вам действительно нужны, например: select email from customers where surname=’jones’.
При работе с MySQL ... старайтесь избегать использования шаблона (*) в операторе select (например, select * from mytable). Это кажется очень удобным, но запрос будет выполняться намного медленнее и создавать дополнительный сетевой трафик. Вместо этого указывайте только те поля, которые вам действительно нужны, например: select email from customers where surname=’jones’.
12. Viper - 08 Марта, 2007 - 17:11:27 - перейти к сообщению
-SCHATTEN- пишет:
Вообще MySQL считается одной из самых быстрых БД. В ней упор поставлен на быстродействие, но для достижения этой цели в ней не полностью реализован SQL в ней отсутствует транзикации, которые замедлили бы её работу. Кроме этого она плохо работает с большим количеством информации.
Так что MySQL врят ли подойдет в качастве БД в твоем случае.
Так что MySQL врят ли подойдет в качастве БД в твоем случае.
уже пробую на Oracle перенести... но пока мало доков прочитал по работе с этой базой...
13. -SCHATTEN- - 08 Марта, 2007 - 17:27:15 - перейти к сообщению
Если есть время то на сайте http://samouchka[dot]net есть книга по этой БД, поищи...