Comments 26
Спасибо за позновательный материал.
Аргументируйте пожалуйста ваши выводы:
>> однако требует более внимательного подхода со стороны разработчика, а также накладывает
>> довольно серьёзные ограничения на хранимые данные и на функциолнал СУБД.
и
>> использовать PostgreSQL. Это позволит сильно упростить разработку и отладку приложений.
С чего вы это взяли, объясните, о каких ограничениях на хранимые данные и упрощениях разработки идет речь.
>> однако требует более внимательного подхода со стороны разработчика, а также накладывает
>> довольно серьёзные ограничения на хранимые данные и на функциолнал СУБД.
и
>> использовать PostgreSQL. Это позволит сильно упростить разработку и отладку приложений.
С чего вы это взяли, объясните, о каких ограничениях на хранимые данные и упрощениях разработки идет речь.
Касательно ограничения на хранимые данные был приведён пример с длинной строки в уникальном столбце. Вернее даже не ограничение, а тонкость использования. А использование слова «серьёзные» вызвано моими эмоциями.
Что же касается «использовать PostgreSQL. Это позволит сильно упростить разработку и отладку приложений.» — приношу извинения, действительно погорячился, сейчас исправлю.
Что же касается «использовать PostgreSQL. Это позволит сильно упростить разработку и отладку приложений.» — приношу извинения, действительно погорячился, сейчас исправлю.
> Вобщем, для проектов не ориентированных на многомиллионную посещаемость, а также в академических целях я рекомендую использовать PostgreSQL. Это позволит сильно упростить разработку и отладку приложений.
Бред.
Бред.
Вобщем, для проектов не ориентированных на многомиллионную посещаемость, а также в академических целях я рекомендую использовать PostgreSQL.
тут можно спорить. хайлоад проект может иметь сложную логику запросов к БД, а может и простую. например ютуб сидит на мускуле, а imdb на постгресе. оба проекта хайлоад. имхо, imdb помедленнее ютуба будет, но логика запросов там (на imdb), как мне кажется, посложнее.
MySQL показывает своё преимущество исключительно на базах данных с большим количеством простых однотабличных запросов и требует к себе пристального внимания со стороны разработчкиа.
насчет запросов согласен, а вот насчет «пристального внимания со стороны разаботчика»… 0_о это о чем вообще?
Под «пристальным вниманием со стороны разаботчика» я имел в виду то, что MySQL довольно сильно отличается от «других» баз данных тем, что разработчику с академическими знаниями по БД, или просто изучающему SQL будет сложнее работать с MySQL. Точно также как и знание только MySQL может породить неправильное понимание баз данных. Кроме того, пункт про преждевременное ограничение длинны текстовых данных тоже сюда относится. Размер BLOB тоже довольно неожиданный.
А про «Вобщем, для проектов не ориентированных на многомиллионную посещаемость, а также в академических целях я рекомендую использовать PostgreSQL» могу заметить, что, во-первых, это моё личное мнение и мой личный опыт. Во-вторых там не сказано, что я «не рекомендую использовать PostgreSQL для хайлоада».
А про «Вобщем, для проектов не ориентированных на многомиллионную посещаемость, а также в академических целях я рекомендую использовать PostgreSQL» могу заметить, что, во-первых, это моё личное мнение и мой личный опыт. Во-вторых там не сказано, что я «не рекомендую использовать PostgreSQL для хайлоада».
что разработчику с академическими знаниями по БД
Разработчик с академическими знаниями это не разработчик, а студент.
Для желающих PostgreSQL предлагает целую группу типов данных для работы, которые напрочь отстутствуют в MySQL:… типы для хранения IP и MAC адресов, и даже типы для хранения параметров геометрических фигур.
1) По ip. Типа нет, есть функции преобразования в INT.
2) MAC — нет. Хотя я не вижу смысла для каждого типа данных заводить отдельный тип в БД.
3) Геометрические фигуры, а так же функции и индексы для работы с ними есть.
opengis-geometry-model
Использование БД в HighLoad проектах зависит только от прямоты рук разработчиков.
Разработчик с академическими знаниями это не разработчик, а студент.
Для желающих PostgreSQL предлагает целую группу типов данных для работы, которые напрочь отстутствуют в MySQL:… типы для хранения IP и MAC адресов, и даже типы для хранения параметров геометрических фигур.
1) По ip. Типа нет, есть функции преобразования в INT.
2) MAC — нет. Хотя я не вижу смысла для каждого типа данных заводить отдельный тип в БД.
3) Геометрические фигуры, а так же функции и индексы для работы с ними есть.
opengis-geometry-model
Использование БД в HighLoad проектах зависит только от прямоты рук разработчиков.
какой смысл сравнимать мускул и постгри? тут больше подойдет сравнение оракл и постгри. Это совершенно разные БД под разные задачи и разную нагрузку
тоже самое что сравнивать жигули и камаз
тоже самое что сравнивать жигули и камаз
у MySQL есть тоже свои специфические типы — например enum
Который является обычным бигинтом, но это поле мне почему-то не нравится. Если совсем уж приспичело хранить флажки, я бы посоветовал использовать старый добрый инт и вытаскивать флаги старым всемилюбимым побитовым и (&) Сишники их очень любят :)
В PostgreSQL он так же есть =)
эээ… мне кажется что он не в том виде в каком в MySQL есть, если как varchar с ограничением, то это вообще не то.
На счет специальных типов данных в Постгре: вместо этого в МуСКуЛе много встроенных функций.
Например, зачем отдельный тип данных для IP адреса, если в есть функции штуе_aton ( IP адрес в целое число), и обратно — штуе_ntoa. это стандарт во всех языках программирования.
Например, зачем отдельный тип данных для IP адреса, если в есть функции штуе_aton ( IP адрес в целое число), и обратно — штуе_ntoa. это стандарт во всех языках программирования.
UFO just landed and posted this here
Индексы и ключи
На этом фронте MySQL тоже не блещет своими возможностями. Ограничение в 1000 байт на размер ключа — куда это годится? Допустим, я разрешаю своим пользователям создавать учётные записи на любом языке (UTF-8). В качестве максимальной длинны логина я выбираю 512 символов...
Пример надуманный.
Или автор действительно использует логины из 512 символов?
Вот тут человек разочаровывается в MySQL:
Да, осадочек неприятный…
Ваш MySQL - то еще Г...
Написано 05.10.08 12:17
Сегодня с утра один из моих сайтов запел, что Table '..../cache_block' is marked as crashed and should be repaired
Ну я ее, конечно REPAIR TABLE, но осадок остался. MySQL несколько месяцев никто не перезапускал, сервер тоже не падал:
12:21PM up 124 days, 21:33, 1 user, load averages: 3,48 3,59 3,63
Надо ли говорить, что на гораздо более интенсивной эксплуатации другой опенсорсной базы я на такие грабли не наступал.....
Поставить mysqlcheck в крон?
Да, осадочек неприятный…
мне кажется не совсем корректно так сравнивать.
mysql — система с pluggable storage engines, и между myisam и innodb разница огромная, вообще не совсем корректно сравнивать isam и транзакционные движки, у них разные области применения. в postgresql же один движок.
а если сравнивать innodb и postgresql то они в целом одинаково хороши, все эти различия небольшие это фигня и за неделю привыкаешь, разве что innodb несколько сложнее настраивать, там много таких неочевидных крутилок, на знании которых прекрасно зарабатывают консультанты по mysql performance ;)
mysql — система с pluggable storage engines, и между myisam и innodb разница огромная, вообще не совсем корректно сравнивать isam и транзакционные движки, у них разные области применения. в postgresql же один движок.
а если сравнивать innodb и postgresql то они в целом одинаково хороши, все эти различия небольшие это фигня и за неделю привыкаешь, разве что innodb несколько сложнее настраивать, там много таких неочевидных крутилок, на знании которых прекрасно зарабатывают консультанты по mysql performance ;)
Sign up to leave a comment.
Сравнение MySQL и PostgreSQL с точки зрения разработчика