Представлена (http://www.postgresql.org/about/news.1125) первая альфа-версия PostgreSQL 8.5. В течении 2 месяцев планируется выпустить три или четыре альфа-версии, после чего будет выпущен бета-релиз. Из новшеств (http://developer.postgresql.org/pgdocs/postgres/release-8.5....) можно отметить:- Возможность задания флага DEFERRABLE для выражений с признаком UNIQUE;
- Поддержка конструкции IF EXISTS в DROP COLUMN/CONSTRAINT;
- Возможность вывода результатов работы EXPLAIN в XML и JSON форматах;
- Новый шестнадцатиричный формат ввода и вывода для типа данных BYTEA
- Поддержка многопоточности в утилите pgbench, что позволяет задействовать все CPU в системе и сгенерировать более реалистичную тестовую нагрузку;
- Улучшение в системе сборки и уточнение документации;
- В будущих альфа-версиях PostgreSQL 8.5 планируется добавить поддержку режима "горячего резерва", с возможностью выполнения select запросов на запасном сервере.URL: http://www.postgresql.org/about/news.1125
Новость: http://www.opennet.me/opennews/art.shtml?num=23154
Поддержка конструкции IF EXISTS в DROP COLUMN/CONSTRAINT;хорошо
И опять же вопрос: как там с 1С?
Лучше бы допилили partitioning с нормальными индексами и без того изврата, что есть сейчас при добавлении/удалении записей с использованием тригеров.
А еще добавили бы, как в mysql, возможность ALTER TABLE ADD COLUMN [BEFORE,AFTER] column.
Я писал об этом везде где можно, и на http://postgresmen.ru/ на форуме в пожеланиях на будущие релизы и разработчикам, но так никто даже не почесался.
Без BEFORE,AFTER уж очень неудобно при изменении структуры таблицы, нарушается вся логика следования колонок.
Может здесь кто-то услышит меня. ;-)
>А еще добавили бы, как в mysql, возможность ALTER TABLE ADD COLUMN
>[BEFORE,AFTER] column.
>Я писал об этом везде где можно, и на http://postgresmen.ru/ на форуме
>в пожеланиях на будущие релизы и разработчикам, но так никто даже
>не почесался.
>Без BEFORE,AFTER уж очень неудобно при изменении структуры таблицы, нарушается вся логика
>следования колонок.
>Может здесь кто-то услышит меня. ;-)что-то спорная полезность данной фичи на мое имхо
> что-то спорная полезность данной фичи на мое имхотогда вы не разрабатывали/поддерживали большие проекты.
рекомендую ознакомиться:
http://wiki.postgresql.org/wiki/Alter_column_position
>> что-то спорная полезность данной фичи на мое имхо
>
>тогда вы не разрабатывали/поддерживали большие проекты.
>рекомендую ознакомиться:
>http://wiki.postgresql.org/wiki/Alter_column_position1) physical layout can be optimized by putting fixed size columns at the start of the table
Эта фича тогда должна работать автоматически, перестраивая фактический порядок хранения столбцов так, как постгресу покажется более правильным. Указание порядка вручную тут будет, как минимум бесполезным, а, скорее всего, даже и вредным. А до тех пор, пока это не влияет на работу постгреса, смысл переупорядочивания сводится исключительно к следующему пункту.
2) ordering columns can make working with a table easier, either by putting result sets in an order that is visually appealing, or by grouping columns based on similar function within a table.
Во-первых, с "сырым" порядком сталкиваются, преимущественно, разработчики. Пользователи его могут увидеть только в каком-нибудь визуальном редакторе, типа редактора отчетов OpenOffice.org Base. У меня есть пара долгоживущих проектов, в которых около сотни таблиц, которые регулярно дополняются новыми столбцами. Никого их реальный порядок пока особо не беспокоил.
Возможно, это связано с тем, что нигде не применяется запросов вида "SELECT * FROM table" и "INSERT INTO table VALUES ()". Всегда указывается список столбцов в ожидаемом порядке. Аргумент "мне лень перечислять 50 столбцов" не приводить. Мне вот лень размеры буферов проверять в C, но тем не менее.Собственно, я-то не против этой фичи, но ресурсы разработчиков я бы предпочел направить на более полезные задачи.
так я как раз и ратую, с точки зрения разработчика больших высоконагруженных распределенных систем, которые в дальнейшем приходится поддерживать и дорабатывать.с точки зрения пользователя, эта, как и многое и многое вобще не важно, главное чтоб работало и выполняло свои задачи.
>так я как раз и ратую, с точки зрения разработчика больших высоконагруженных распределенных систем100 к 1 - ты таких систем даже на картинках не видел :)
> тогда вы не разрабатывали/поддерживали большие проекты.эта фича нужна только для запросов содержащих в себе логическую бомбу. достаточно НЕ ПРИМЕНЯТЬ select * и все будет хорошо.
а за select * направлять на дообучение или увольнять за профнепригодность.
> эта фича нужна только для запросов содержащих в себе логическую бомбу. достаточно НЕ ПРИМЕНЯТЬ select * и все будет хорошо.
> а за select * направлять на дообучение или увольнять за профнепригодность.глупости. при запросах select * все нормальные люди используют ассоциативные массивы, и как раз тут структура данных и следование столбцов играют маловажную роль.
так же использовать запросы select * в большинстве случаев не имеет смысла из-за падения скорости и увеличении трафика, для передачи лишних, не нужных данных.
Какая вам разница, как столбцы хранятся в базе?
Постройте в SELECT нужный порядок и забудьте уже про фактический порядок столбцов.
Это вам, в конце-концов, не dbf :)
Вот потому я и сказал, что спорная эта фича
Дофига существует больших проектов на PgSQL , и ведь как то обходятся... В Select укажи нужный порядок и усёИ. кстати. я ERP системы на этой СуБД сопровождаю, допиливаю
прошу прощения, с вами лично не знаком, поэтому судить не берусь о вашей компетенции, но как показывает моя практика наличие этой фичи очень сильно помогло бы многим разработчикам, в том числе и мне, т.к. не перевариваю, когда у меня таблицы со временем добавления других колонок теряют свою элегантность, а так же производительность и объем на диске.
я например, все fk размещаю в начале таблицы, а все varchar'ы и blob'ы в конце, а при вашем подходе будет каша.сейчас же обходятся очень просто, читайте по этой ссылке на официальной wiki проекта, что я выше уже приводил:
http://wiki.postgresql.org/wiki/Alter_column_positionкак вы рассуждаете, можно так же и о partitioning рассуждать, про который я выше написал и про master-master.
ведь как-то обходимся триггерами и кучей костылей.
хотя и радует, что из-за таких левых костылей появились такие замечательные проекты, как PL/Proxy.
Порядок столбцов это костыль к реляционной теории.
Реляционные БД потому так и популярны (читай надежны, быстры, удобны), что базируются на теоретической основе.
Поэтому разработчики во первы 10раз подумают над этим, во вторых сделают когда нечем будет заняться.
а вы, простите, разработчик, чтоб за них говорить? я все же надеюсь, что этот вопрос будет решен в ближайшее время, иначе так и будем писать левые костыли для переноса данных между старыми и новыми структурами данных и терять драгоценное время разработчиков в погоне за идеальной структурой.структура и порядок столбцов важна, хотя бы для того, чтобы оптимизировать хранения данных на диске и скорость доступа к ним. об этом я и многие другие писали неоднократно.
что касаемо реляционных бд, то они популярны только из-за того, что на данный момент ничего удобней нет, а во всем остальном, они не надежны, не быстры и не удобны для большинство более менее серьезных задач.
структура, порядок, секционирование,... индексирование - задача дба.
каждая бд (даже оного и того же приложения) - уникальна и зависит от специфики предприятия, софта, железа и т.д.
все аргументы банально сведутся к - "а вот так на мой ОБЪЕКТИВНЫЙ взгляд красивее".
зы:
программисты! не лезьте туда, куда ВАС не просят и да не посланы будите.
все должно быть идеально, начиная от проектирования структуры бд и заканчивая разработкой.
если у вас не проект, а каша, то со временем, время, затраченное на поддержку может возрасти в разы. каша в коде = каша в голове.
так же от правильно выбранной структура размещения колонок можно увеличить производительность и уменьшить объем базы.
Если таблица про существовала скажем год, и вдруг понадобилось добавить колонку без удаления имеющихся данных. С какой такой радости нужно физически двигать имеющиеся данные в соответствии с новой структурой?Это все равно что сделать совершенно новую таблицу, скопировать данные туда, старую удалить, новую переименовать.
Облегчение жизни для использования запросов типа select * from t; вообще не аргумент. Можно создать специальный View, в конце концов, с нужным порядком столбцов.
скопировать туда-сюда - так и работаем сейчас, вместо того, чтобы выполнить одну команду, которая сама на уровне субд сделает за нас всю работу, как это сделано в mysql.
а если на этой таблице навешано куча триггеров и она еще является partitioning таблицей, и на нее еще ссылается куча foreign key и еще куча всего, что реально используется в больших задачах, а не на сайтах за 5 копеек, что тогда делать?
Я лишь одного не понимаю - с чего вы решили что производительность упадёт?
Можно линк на документашку про это?
Или всё таки звеним? :-)
нет времени на поиски. если интересно можете организовать сами тестирование и найти заметки в google.
те тесты, что мы проводили< показывают незначительное падение скорости при выборке и увеличение занимаемого дискового пространства.хотя для меня эта функция нужна больше для удобства при проектировании и поддержке работающих продуктов, т.к. исключает возможные ошибки при включении и отключении триггеров и foreign keys, а так же существенного уменьшении скорости при переходе на новую структуры данных.
Т.е. Вы признаете что попросили от Слонов откровенную глупость? :)
Ну дык вам об этом с самого начала талдычат! :)
Они ребята вежливые, я бы послал - а они написали раздел в доке для желающих странного :)
ничего я не признаю. не нужно передергивать мои слова. тысячам разработчиков приложений под mysql данная функция помогает жить, а для вас она почему-то глупая.
функция необходимая и не только мне, судя по количеству запросов на ее добавление. о ее плюсах я так же написал несколько раз. лично для меня она прежде всего помогла бы с меньшими потерями по времени сохранять структуру данных в том ЛОГИЧЕСКОМ виде, в котором она должна быть при поддержке больших проектов.
p.s. вы для начала научитесь правильно читать и понимать, что пишут люди. раздел в wiki как раз говорит о том, что функция полезная, а вы почему-то видите только то, что хотите видеть.
> тысячам разработчиков приложений под mysql данная функция помогает жить, а для вас она почему-то глупая.Тысячам разработчиков под mysql глубоко всёравно что изменение таблицы блокирует её чтение, это совершенно не мешает им жить :)
Коллега, как Вы предлагаете сочетать эксклюзивную блокировку таблицы необходимую для физической перестройки её структуры на диске с конкурентным доступом к ней и транзакционными областями видимости одной и той же записи ?
Либо Ваши базы настолько "глобальны и надёжны" что легко позволяют отключить всех пользователей на три часа для проведения перестройки таблицы, либо они настолько мизерны что перестраивают всю таблицу за секунду... по-моему Вы просто не понимаете о чём просите...
> а если на этой таблице навешано куча триггеров и она еще является partitioning таблицей, и на нее еще ссылается куча foreign key и еще куча всего, что реально используется в больших задачах, а не на сайтах за 5 копеек, что тогда делать?отказаться от select * и применять select pk, fk1, fk2, fk3
>> а если на этой таблице навешано куча триггеров и она еще является partitioning таблицей, и на нее еще ссылается куча foreign key и еще куча всего, что реально используется в больших задачах, а не на сайтах за 5 копеек, что тогда делать?
>
>отказаться от select * и применять select pk, fk1, fk2, fk3а никто и не использует select *, т.к. тянуть за собой данные, не нужные в запросе, нет смысла, да и еще это сказывается на скорость и трафик при выборке.
>отказаться от select * и применять select pk, fk1, fk2, fk3Что собственно и рекомендуют во всех букварях по SQL ... но парень слишком крут чтоб читать буквари :)
>скопировать туда-сюда - так и работаем сейчас, вместо того, чтобы выполнить одну команду, которая сама на уровне субд сделает за нас всю работу, как это сделано в mysql.создайте уже пару-тройку хранимых процедур для автоматизации данного процесса.
а то не солидно как-то... для конторы не за 5 копеек.
>а если на этой таблице навешано куча триггеров и она еще является partitioning таблицей, и на нее еще ссылается куча foreign key и еще куча всего, что реально используется в больших задачах, а не на сайтах за 5 копеек, что тогда делать?а не за 5 копеек принято пользоваться средствами, которые и умл-диаграммы строят, и скрипты генерят,.. а ежели в хороших руках, то ещё и с комментами и генерацией доков.....
в результате - всё тоже (отключить триггеры, перестроить индексы,.. что там ещё?) должна будет проделать эта команда. а если ещё б/д хранит данные не так просто как майисам (количество таблиц по количеству файлов б/д можно посчитать :-D), то ещё и данные подвигать туда сюда, екстенты добавить/убавить/оптимизировать (ведь не только имя в середину вставляется? это же не вьюха какая-нибудь, не так ли?)... и всё это сопровождается перманентными глюками и багами в особо сложных случаях.нет уж! генерите скриптами, с комментами, со ссылками на номер бага/фичи и чтоб потом не тормозили запросы (когда каждая строка по всему винту размазана тонким слоем) и т.д. если это так важно клиентам конторы > 5 копеек.
а при разработке - вообще параллельно как там что храниться. лишь бы готовый скрипт генерации б/д был правильный.
>и чтоб потом не тормозили запросы (когда каждая строка по всему винту размазана тонким слоем)БЛИН! Ещё один ... у вас там в мыскле пожар что ли, че вы все сюда то поприпёрлись?
Повторяю большими краснвми буквами - тут вам не мыскыль - наш слоник так данные _НЕ_ хранит, его люди с мозгами делают! (Я вежливый и не сказал "в отличие от!" :)
ВАШ слоник? :-DDDDDDDDDDDDDDDDDDDDDDD
ну так держите его при себе.читаешь плохо? нет?
а если хорошо, то возьми и реализуй эту фичу.
да так, чтоб не как в.. как тут "культурные" люди говорят?.. мыскле? :-DDDDDD
и чтоб не по всему винту, и быстро, и без блокировок.....ну а потом приходи выпендриваться дальше.
"Лучше бы допилили partitioning с нормальными индексами и без того изврата, что есть сейчас при добавлении/удалении записей с использованием тригеров."
Присоединяюсь