Сравнение на ms sql и postgresql. Изберете subd между mysql, postgresql, mariadb и mssql? Ефективност и сложност на администрацията

Нека бъдем честни, въпреки че 1C Enterprise е съвместим с много СУБД, всъщност 99 процента работят или в MS SQL, или в безплатен PostgreSQL.

С други думи, тези две „под-евтини“ завладяха пазара на клиент-сървър 1C.

И можем спокойно да предположим, че ако една компания не работи в MS SQL, тогава най-вероятно просто използва PostgreSQL.

Съответно има смисъл да се сравнява Postgres само с MS SQL.

Днес пишат много, както за MS SQL, така и за PostgreSQL, но обикновено не ги сравняват обективно.

В тази статия ще анализираме основните технически точки на безплатния PostgreSQL, сравнявайки го с MS SQL.

Това ще ви позволи в бъдеще да направите най-добрия избор и да сте готови за различни "изненади" или какво ще е по-правилно за "особенностите" на работа в тази безплатна СУБД.

Ще оценим всичко както е, без да добавяме към Postgres онези достойнства, които той няма и без да украсяваме платения MS.

Веднага ще отговоря на въпроса, който тревожи много начинаещи!

ДА! MS SQL е по-бърз от PostgreSQL, това е факт! И има редица причини за това!

Може би веднага разочаровах някого и може би не сте съгласни с това твърдение, извинявам се, но самата физика на тази безплатна СУБД не й позволява да изпревари MS SQL, особено ако говорим за такъв пакет като "Monster 1C" и PostgreSQL.

Често ще срещате подобни аргументи на различни конференции и семинари, посветени на тази СУБД. Никой нищо не крие или отрича, фактът е факт.

Въпреки това производителността на PostgreSQL е достатъчна за потребителите може да работи комфортно в 1C.

Независимо дали става дума за дузина потребители или дори няколкостотин, работещи едновременно в 1C Enterprise.

Защо "Monster 1C"?

Всъщност така 1C вижда PostgreSQL без инсталирани специални "кръпки" и разширения.

Да, както се казва от кутията, като изтеглите дистрибуцията на PostgreSQL в офиса. сайт, няма да можете да го използвате за работа във връзка с 1C. 1C ще се забави ужасно и просто ще спре, ще откаже да работи.

Защо се случва това и защо "кръпки"?

Факт е, че 1C Enterprise създава огромен брой временни таблици в хода на работата си, можем да говорим около хиляди таблици в секунда,и ако вземете например регистъра "Разрез на последното" - "Останки и обороти", може да има и милион редада бъде.

Факт е, че по подразбиране (без "кръпки") PostgreSQL не отчита статистики за тези големи временни таблици, с други думи, оптимизаторът на заявки, който се ръководи от данни от статистика (и както си спомняте, той е празен, няма нищо да броим), грубо казано, прави селекция с помощта на метода ИЗБЕРЕТЕ *което разбира се ще работи много, много бавно!

Оттук и грандиозните спирачки в 1С!

Разбира се, това не са всички проблеми, които трябва да бъдат решени, за да може PostgreSQL да работи нормално в тандем с 1C. Ще ни трябват други „кръпки“ и специални разширения, а след 15-20 потребители все повече и повече. настройки в "config"

Да, в действителност всичко изглежда много по-сложно, отколкото описах по-горе, но ето как, ако се опрости значително, ще изглежда основният проблем на бавната работа на 1C с PostgreSQL.

Второто нещо, което силно не харесвам в PostgreSQL, е няма многонишковост в рамките на една заявкав сравнение с MS SQL.

(Започвайки от версия 9.6, направихме първия опит за паралелизиране на заявки, но засега не работи добре, понякога ефектът е обратен). но за опита 5!)

Какво, разбира се, влияе на производителността, така че да разберете с прости думи -

PostgreSQL е в състояние да стартира вашия 48-ядрен сървър с една голяма заявка!

Всичко е просто, няма паралелизиране на нишки в рамките на една заявка, а една голяма заявка "зарежда" само едно ядро.

Да, ако има много заявки, тогава всички ядра ще бъдат заредени и всичко ще работи добре.

И почти забравих ние сравняваме PostgreSQL с MS SQL Standard, а не Express!

Express, въпреки че може да се използва за търговски цели, има редица ограничения.

като 10 GB на база, използване на един процесор, 1 GB RAM,

прави използването на такъв продукт почти нереалистично за работа в 1C Enterprise.

Освен ако нямате много малка база и само няколко потребители (и дори тогава има много малко спирачки на 1 GB DBMS).

Така че нека сравним PostgreSQL с популярната стандартна версия.

СЦЕНАРИ !!!

PostgreSQL е предимно скриптове в сравнение с MS SQL, повечето от операциите трябва да се извършват на ръка, да, разбира се, можете да инсталирате някои основни неща чрез интерфейса, но подчертавам, че основният, а стъпка вляво е стъпка вдясно и трябва да напишете скрипт или BASH на Linux или cmd, powershell на Windows.

Преглеждайте и анализирайте следи с помощта на SQL Server Profiler.

Добре познатият SQL Server Profiler отсъства в PostgreSQL, а под думата „отсъстващ“ имам, ще ви представя напълно, уви, в PostgreSQL няма нищо подобно.

Има, разбира се, помощни програми, които позволяват, ако имате време да прихванете заявка или да зададете точка на прекъсване на 1C в дебъгера и да получите нещо и да видите, но в сравнение с Profiler, както се казва, не беше дори близо.

Можете да настроите дневник и след това да го повторите - но за дълго време!

Ето един пример:

1C програмист се опитва да отстрани грешка в някаква голяма заявка, отнема много време, например 30 минути, и така в PostgreSQL, за да влязат данните в дневника, тази заявка трябва да бъде изпълнена! Можете ли да си представите колко време можете да отстраните грешки в такава заявка?

Докато в MS SQL можете да прекъснете изпълнението на заявка и да я анализирате в Profiler, тъй като тя вече ще бъде там, но със състояние „неуспешно“.

По отношение на вида на „резервните копия“ Postgres няма равен!

Тук ще намерите инкрементално архивиране и пълно архивиране и непрекъснато WAL архивиране.

Всъщност има частично архивиране и частично възстановяване на данни.

Можете да конфигурирате непрекъснато архивиране и възстановяване в момента (Възстановяване във времето (PITR)).

Също репликация, е наличен в PostgreSQl без никакви "кръпки" на помощни програми и добавки!

• Каскадна репликация
• Поточно репликация
• Синхронна репликация
• Непрекъснато архивиране на сървър в режим на готовност

Всичко това е там, първоначално вече в PostgreSQl и разбира се не в "експресната" и не е налично във версията MS SQL Standard.

За да получите всичко изброено по-горе в MS SQL, трябва да закупите много скъп MS SQL Enterprise, сега нещо около 15 000 долара.

Какво липсва в сравнение с MS SQL?

БЕЗ диференциално "резервно"

Да, няма диференциално "резервно копие" в PostgreSQl, но има различни аналози на инкрементални "резервни копия".

Например инкрементално архивиране на ниво блок.

ИМА разделение на TABLESPACEs, което вече поддържа 1C по подразбиране!

Което, между другото, не е в MS SQL!

Например, можете да конфигурирате на кой диск ще имате „индекси“ и на кой диск ще бъде разположена „таблицата“, което е много удобно при планиране на ИТ инфраструктура, когато става въпрос за големи 1C бази данни. ONLINE_ANALYZE, за да преизчислите статистиката. Същото важи и за * dt файла.

С помощта на PostgreSQl рядко се нуждаете от REINDEX!

Всъщност той трябва да се използва само когато има подозрение, че целостта на базата данни е била повредена.

Можете да правите "резервни копия" с изключение на таблици!

Например, имате няколко програмисти на 1C, работещи във вашата компания, те гарантирано ще правят резервни копия за себе си, създават "резервни копия" за по-нататъшно развитие.

В резултат на това потребителите страдат, базата данни се забавя по време на създаването на голямо "резервно копие", особено ако тази база данни съдържа такива неща като различни прикачени файлове, архиви, документи от писма. Такива файлови таблици могат лесно да съдържат стотици гигабайта. И те също могат да бъдат изключени в PostgreSQl чрез създаване на "резервно копие", което по този начин е малко по размер и с цялата функционалност едновременно.

Така че не зареждаме мрежови устройства още веднъж, не запушваме канала, прекарваме много по-малко време за създаване на такова "резервно копие"

В крайна сметка всички печелят! Потребителите, програмистите и администраторите спят добре.

В тази статия анализирахме само основните разлики между PostgreSQl и MS SQL, (има и други), но ще вземем решение за избор в полза на една или друга СУБД, статията трябва да помогне!

Успех колега!

P.S. Сега работя върху нов курс "1C и PostgreSQL" (Вече на етап запис, чакайте скоро!)

С най-добри пожелания, Богдан.

Във връзка с бързото обезценяване на рублата стана много скъпо закупуването на Microsoft SQL СУБД, а за някои компании цената на тези лицензи стана доста „недостъпна“. В момента, за да внедрите Microsoft SQL Server за 20 потребители, трябва да закупите следните лицензи:

1 лиценз за операционна система (WinSvrStd 2012R2)

20 лиценза за сървърна връзка (WinSvrCAL 2012)

1 лиценз за DBMS сървър (SQLSvrStd 2014)

20 лиценза за свързване към СУБД (SQLCAL 2014)

Приблизителна цена на такъв пакет 275 000 рубли,което е доста скъпо за компания само с 20 човека. Тези разходи могат да бъдат избегнати чрез създаване на безплатен софтуерен сървър на база данни. Инсталирайте операционна система от семейството на Linux и безплатна версия на СУБД - PostgreSQL. На такъв сървър можете лесно да разположите корпоративен 1C сървър, както и други роли, които потенциално могат да бъдат комбинирани с ролята на бази данни, например WebServer или съхранение на файлове.

Тъй като използването на безплатен софтуер е много привлекателно от финансова гледна точка, беше решено да се тества колко е добър от гледна точка на производителността.

Тестване на производителността на 1C:

За провеждане на теста използвахме хардуера и софтуера, посочени в Таблица 1. Физическият сървър за двата щанда беше един и същ, само софтуерът беше променен. Настройките на двете СУБД са използвани по подразбиране и не ги описваме подробно в статията. Комплектът за разпространение на PostGreSQL със съответните пачове е взет от сайта 1C, версията е най-новата налична на този сайт.

Таблица 1. Изпитателни стендове

Като начало беше направен „тест на Гилев”, който показа леко предимство на стенд номер 2, спрямо стойка със свободен софтуер.

Вижте резултатите по-долу, разликата в стойностите е само 3%.

За информация:"Тестът на Гилев" е популярен синтетичен 1С тест, който извършва редица стандартни операции - колкото по-бързо се извършва тестът, толкова по-висок е резултатът. Оценката се извършва в конвенционални единици. Полученият резултат може да се сравни със скалата, приложена към теста, която ще покаже колко висока е производителността на текущата система.

Фигура 1. Резултат от теста на Гилев. Стенд No2 СУБДГОСПОЖИЦА SQL

Фигура 2. Резултатът от теста на Гилев. Стенд No1 СУБДPostgreSQL

Освен това беше решено да се извърши тестване по метода APDEX. Същността на метода е да се измери времето за изпълнение на основните операции в 1C, измерванията се правят няколко пъти за определен период от време. След това резултатът се сравнява с приемливото време за изпълнение за конкретна операция.

За да направим това, взехме реална работна база на една от най-тежките конфигурации 1C, характеристиките на основата са показани в таблица № 2.

Таблица 2. Характеристики на тестовата база

Измерено е времето за изпълнение на 7 стандартни операции с обекти в базата данни. Всеки тест се провежда 10 пъти и се показва средната стойност. Измерванията са направени с помощта на дебел клиент през локална мрежа. Клиентът беше инсталиран на работна станция с Windows 7. Опитахме се също да стартираме тестовете от клиента, инсталиран на Ubuntu Linux, но той не работи стабилно и беше решено всички тестове да се изпълняват само от клиента на Windows.

Таблица 3. РезултатиAPDEX

Средно нашата реална база, използваща MSSQL, работи с 45% по-бързо, отколкото на щанда с безплатен софтуер. При някои тестове разликата беше много значителна, а при такива като например нов документ беше само 11%.

Изход:

1Cработи на MSSQL DBMS около 1,5 пъти по-бързо, отколкото на PostgreSQL. Съответно, ако е възможно да закупите или наемете MSSQL лицензи, по-добре е да го използвате за по-висока производителност. За малки и леки бази данни можете да опитате да използвате версията MSSQL Express. Не проведохме тестове с него, така че той може да се покаже в производителност като по-добър или по-лош от PostgreSQL. Това издание е ограничено до използването на 1 процесор и 1 GB RAM; също така не работи с бази данни по-големи от 10 GB. Ако базата данни нарасне до този размер, тогава тя ще спре и ще спре да работи напълно, но както показва практиката, ако 15-20 потребители работят в базата данни, тогава можете удобно да работите с размер на база данни от 4-5 GB, тогава базата започва да забавя много.

Оценката от "теста на Gilev" показва изключително незначително превъзходство на MSSQL, което ни позволява да направим предположение, че други 1C бази данни могат да работят както на PostgreSQL, така и на MSSQL, и вероятно по-бързо. Преди да изберете СУБД, препоръчваме да проведете тестове на вашата конкретна база данни и да сравните резултатите.

Използването на СУБД PostgreSQL за внедряване на 1C върху нея е приемливо решение при ограничен бюджет. Базата данни няма да работи толкова бързо, колкото в MSSQL, но не е необходимо да плащате за лицензи.

В края на 2017 г. проведохме нови тестове и ги публикувахме в друга статия.

Друг начин да спестите пари при използване на 1C е решението - да наемете 1C сървър.

Системна интеграция. Консултиране

Ключът на сървъра е необходим за стартиране на 1C Server (нека го наречем 1C App).
Необходим е сървър 1C - така че базата данни да не е файл, а на три нива.
Три връзки, тя също е на ниво труд, има модел на взаимодействие 1C Client<->1С приложение<->СУБД (MS SQL, DB2, Oracle, PostgreSQL)
Тези. клиентът всъщност не комуникира със сървъра на СУБД, той комуникира със сървъра 1С, а той от своя страна комуникира със СУБД.
По този начин можете да имате 2,3,5-25-125 DBMS сървъра и само един 1C сървър. Само за всяка база данни на 1C сървъра ще трябва да посочите на кой сървър е инсталирана конкретна база данни и какъв вид сървър е (тип СУБД).

Ключът за 1C сървъра струва ~ 42 тр. за 32-битовата версия и ~ 74 тр. за 64 бита. В този случай ключът за 64-битовата версия може да се използва за 32-битов сървър (напротив, разбира се, това е невъзможно).
Като ключ за сървъра смятам, че е по-разумно да се използва хардуерен ключ.

Между другото, относно лицензирането:

- евтин нахален
Да, има версия за доставка 1C с включен MS SQL лиценз. Но:
а.За да получите такава доставка, трябва да закупите комплект: 1C сървър + MS SQL + поне 5 клиентски лиценза (правилно, ако греша, възможно е да трябва да закупите поне 10 клиента)
което в случай на вече закупени 1C ключове значително намалява рентабилността на такова придобиване.
б.Съгласно условията на лиценза, тази скула може да се използва САМО за 1Ski.
Тези. Изглежда, че можете да разположите друга база данни върху нея, но по този начин веднага ще превърнете лицензиран MS SQL в нелицензиран.

- правилно лицензиране -
Според правилата лицензирането на MS SQL трябва да се извършва като сървърен лиценз + лицензи за клиентска връзка.
Където за "клиент" се счита не 1C App с една връзка (може да има повече връзки - в зависимост от това колко процеса конфигурирате на сървъра), а всеки 1C + 1 потребител лиценз за 1C App

Или лицензиране от сървърни процесори.
Освен това може и да греша, но в случай на 2005 - 2008 MS SQL, трябва да лицензирате сокет (т.е. физически процесор, ако броят на ядрата не надвишава 4x), в случай на 2012 лицензирането отива на процесора CORE на цена = цена на лиценза * брой ядра / 4.
Освен това в ORACLE такава система за лицензиране се използва от дълго време (има таблица с коефициенти в зависимост от общия брой сървърни ядра),
от съвременните инструменти за виртуализация позволяват поне 4, поне 64 физически 4-6-8 ядрени процесора да бъдат представени на виртуална машина като 1 физически с +100500 ядра (които някои успешно използват)

- общо лицензиране -
Много често се купува само сървърен лиценз (~ 28 000 рубли) и е напълно затрупан от лицензирането на клиентски връзки.
В някои случаи, например, в случай на Предприемаческо споразумение, това е допустимо (тъй като лицензът за клиентската ОС под лиценза автоматично дава лиценза за връзката със сървъра).
Но повечето от тях нарушават лицензирането. Въпреки че скулата в същото време бракониерства и не псува.

Релационните бази данни се използват от дълго време. Те станаха популярни заради системите за управление, които реализират релационния модел толкова добре, че това е най-добрият начин за работа с данни, особено за критични приложения и услуги.

MySQL съществува от дълго време и се утвърди като отлично решение, Postgresql излезе на пазара приблизително по същото време, но предоставя много интересни функции и възможности, благодарение на които бързо набира популярност. В тази статия ще се опитаме да сравним MySQL срещу Postgresql, да сравним основните разлики между тези системи, да разберем как работят и да се опитаме да разберем коя система ще бъде по-добра за вашия проект.

Базите данни са предназначени за структурирано съхранение и бърз достъп до различни данни. Всяка база данни, освен самите данни, трябва да има определен модел на работа, според който ще се извършва обработката на данните. За управление на бази данни се използват СУБД или системи за управление на бази данни, като такива програми включват MySQL и Postgresql.

Системите за управление на релационни бази данни ви позволяват да разполагате данни в таблици, като свързвате редове от различни таблици и по този начин свързвате различни, логически комбинирани данни. Преди да можете да записвате данни, трябва да създадете таблици с определен размер и да посочите типа данни за всяка колона. Колоните представляват полета с данни, а самите данни са подредени в редове. И двете системи за управление на бази данни и MySQL срещу Postgresql са релационни. След това ще разгледаме по-отблизо как се различават двете програми. Сега нека преминем към по-подробно разглеждане.

Разказ

MySQL

Разработката на MySQL започва през 90-те години. Първото вътрешно издание на базата данни се състоя през 1995 г. През това време няколко компании участваха в разработването на програмата. Разработката започна от шведската компания MySQL AB, която беше придобита от Sun Microsystems, която всъщност стана собственост на Oracle. В момента, от 2010 г., Oracle се развива.

Postgresql

Разработката на Postgresql започва през далечната 1986 г. в стените на Калифорнийския университет в Бъркли. Разработването продължи почти осем години, след което проектът беше разделен на две части, търговската база данни IIlustra и напълно безплатния проект Postrgesql, който се разработва от ентусиасти.

Хранилище за данни

MySQL

MySQL е релационна база данни, различни двигатели се използват за съхраняване на данни в таблици, но работата с двигатели е скрита в самата система. Двигателят не влияе върху синтаксиса на заявките и тяхното изпълнение. Поддържат се следните основни двигатели: MyISAM, InnoDB, MEMORY, Berkeley DB. Те се различават един от друг по начина на запис на данните на диск, както и по методите за четене.

Postgresql

Postgresql е обектна релационна база данни, която работи само на един механизъм за съхранение. Всички таблици са представени като обекти, могат да бъдат наследени и всички действия с таблици се извършват с помощта на обективно ориентирани функции. Както в MySQL, всички данни се съхраняват на диск, в специално сортирани файлове, но структурата на тези файлове и техните записи е много различна.

SQL стандарт

Независимо от използваната система за управление на база данни, SQL е стандартизиран език за изпълнение на заявки. И се поддържа от всички решения, дори MySQL или Postgresql. SQL стандартът е разработен през 1986 г. и през това време вече са пуснати няколко версии.

MySQL

MySQL не поддържа всички нови функции на стандарта SQL. Разработчиците избраха този път на развитие, за да поддържат MySQL лесен за използване. Компанията се опитва да отговаря на стандартите, но не за сметка на простотата. Ако дадена функция може да подобри използваемостта, тогава разработчиците могат да я внедрят като разширение, независимо от стандарта.

Postgresql

Postgresql е проект с отворен код, разработен е от екип от ентусиасти, а разработчиците се опитват да спазват SQL стандарта колкото е възможно повече и да внедрят всички най-нови стандарти. Но всичко това води в ущърб на простотата. Postgresql е много сложен и поради това не е толкова популярен като MySQL.

Възможности за обработка

Други разлики между postgresql и mysql произтичат от предишния параграф, това са възможности за обработка на данни и ограничения. Естествено, съответствието с по-новите стандарти предоставя по-нови възможности.

MySQL

Когато изпълнява заявка, MySQL зарежда целия отговор на сървъра в паметта на клиента; при големи количества данни това може да не е много удобно. По принцип Postgresql превъзхожда Mysql по отношение на функциите, ще разгледаме кои по-късно.

Postgresql

Postgresql поддържа използването на курсори за навигация през получените данни. Получавате само указател, целият отговор се съхранява в паметта на сървъра на базата данни. Този указател може да се запази между сесиите. Той поддържа изграждане на индекси за няколко колони на таблица наведнъж. В допълнение, индексите могат да бъдат различни типове, с изключение на хеш и b-дърво, GiST и SP-GiST са налични за работа с градове, GIN за текстово търсене, BRIN и Bloom.

Postgresql поддържа регулярни изрази в заявки, рекурсивни заявки и наследяване на таблици. Но има няколко ограничения, например, можете да добавите ново поле само в края на таблицата.

производителност

Базите данни трябва да бъдат оптимизирани за средата, в която ще работите. В исторически план MySQL е бил фокусиран върху максимална производителност, докато Postgresql е проектиран като много адаптивна и стандартно съвместима база данни. Но с течение на времето Postgresql получи много подобрения и оптимизации.

MySQL

В повечето случаи за организиране на работа с база данни в MySQL се използва таблица InnoDB, тази таблица е B-дърво с индекси. Индексите ви позволяват да извличате данни от диска много бързо и това ще изисква по-малко операции с диск. Но сканирането на дърво изисква намиране на два индекса, което вече е бавно. Всичко това означава, че MySQL ще бъде по-бърз от Postgresql само при използване на първичен ключ.

Postgresql

Цялата заглавна информация за Postgresql таблици е в паметта. Не можете да създадете таблица, чиято памет е изчерпана. Записите в таблицата са сортирани по индекс, така че можете да ги извлечете много бързо. За по-голямо удобство можете да приложите множество индекси към една и съща таблица.

Като цяло PostgreSQL е по-бърз, с изключение на използването на първични ключове. Нека да разгледаме няколко теста с различни операции:

Типове данни

Един от акцентите на двете бази данни е поддържаните типове данни, които можете да използвате. Тъй като и двете решения се опитват да съответстват на синтаксиса на SQL, те имат сходни набори, но все пак се различават по някакъв начин.

MySQL

MySQL поддържа следните типове данни:

• TINYINT: много малко цяло .;
• SMALLINT:малко цяло;
• СРЕДНА ИНФОРМАЦИЯ:средно голямо цяло;
• INT:цяла с нормален размер;
• BIGINT:голямо цяло;
• FLOAT:номер с плаваща запетая със знак с единична точност;
• ДВОЙНА, ДВОЙНА ТОЧНОСТ, ИСТИНСКИ:число с плаваща запетая със знак с двойна точност
• ДЕСЕТИЧЕН, ЧИСЛО:подписан номер с плаваща запетая;
• ДАТА:дата;
  ВРЕМЕ ЗА СРЕЩА:комбинация от дата и час;
• ЧАС:времеви печат;
• ВРЕМЕ:време;
  ГОДИНА:година във формат ГГ или ГГГГ;
• CHAR: низ с фиксиран размер, допълнен отдясно с интервали до максималната дължина;
• VARCHAR:низ с променлива дължина;
• TINYBLOB, TINYTEXT:двоични или текстови данни с максимална дължина 255 знака;
• BLOB, ТЕКСТ: двоични или текстови данни с максимална дължина 65535 знака;
• MEDIUMBLOB, MEDIUMTEXT:текстови или двоични данни;
• LONGBLOB, LONGTEXT:текстова или двоична максимална дължина на данните от 4294967295 знака;
• ENUM:прехвърляне;
• КОМПЛЕКТ:комплекти.

Postgresql

Поддържаните типове полета в Postgresql са доста различни, но ви позволяват да пишете точно същите данни:

• bigint: 8-байтово цяло число със знак;
• голям сериал: автоматично нарастващо 8-байтово цяло число;
• малко:двоичен низ с фиксирана дължина;
• малко варира:двоичен низ с променлива дължина;
• булев:знаме;
• кутия:правоъгълник върху равнина;
• байт: двоични данни;
• различен характер:низ от символи с фиксирана дължина;
• герой:
• cidr: IPv4 или IPv6 мрежов адрес;
• кръг:кръг в равнина;
• дата: дата в календара;
• двойна точност:номер с двойна точност с плаваща запетая;
• инет:Интернет IPv4 или IPv6 адрес;
• цяло число: 4-байтово цяло число със знак;
• интервал:месечен цикъл;
• ред:безкрайна права линия върху равнина;
• lseg:сегмент от равнина;
• macaddr:Мак адрес;
• пари:парична стойност;
• път:геометричен път върху равнина;
• точка:геометрична точка на равнина;
• многоъгълник:многоъгълник на равнина;
• истински:еднократно прецизно число с плаваща запетая;
• дребно:двубайтово цяло число;
• сериен:автоматично увеличено четирибитово цяло число;
• текст:низ от символи с променлива дължина;
• време:Часове на деня;
• времева марка:дата и час;
• tsquery: заявка за текстово търсене;
• цветен вектор:документ за текстово търсене;
• uuid: уникален идентификатор;
• xml: XML данни.

Както можете да видите, има повече типове данни в Postgresql и те са по-разнообразни, има типове полета за определени типове данни, които MySQL не прави. Разликата между MySQL и Postgresql е очевидна.

Развитие на

И двата проекта са с отворен код, но се развиват по различни начини. Разработването на MySQL не е по вкуса на всеки. И в това сравнението между mysql и postgresql прави много разлики.

MySQL

Базата данни MySQL се разработва от Oracle и има слухове, че компанията възнамерява да забави развитието на двигателя. Имаше много разклонения на проекта, включително разклонението на MariaDB от оригиналния разработчик на MySQL. Въпреки това развитието остава бавно.

Postgresql

Както беше споменато в началото на статията, разработката започна в университета в Бъркли. След това се премества в търговска фирма. В момента програмата се разработва от независима група програмисти и съвет от няколко компании. Новите версии се пускат доста активно и получават все повече и повече нови функции.

заключения

В тази статия направихме сравнение между mysql и postgresql, разгледахме основните разлики между двете системи за управление на бази данни и се опитахме да разберем коя е по-добра от postgresql или mysql. Като цяло Postgresql е най-добрият по отношение на възможностите, но е сложен и не е универсално приложим. MySQL е по-прост, но му липсват някои интересни функции. Коя база данни ще изберете за вашия проект? Защо точно тя? Пишете в коментарите!

За да завършите видеоклипа, описващ възможностите и перспективите на Postgresql: