|
| 1.3, Аноним (-), 16:51, 25/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Лучше бы допилили partitioning с нормальными индексами и без того изврата, что есть сейчас при добавлении/удалении записей с использованием тригеров.
| | |
| |
| 2.5, Аноним (-), 18:44, 25/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
А еще добавили бы, как в mysql, возможность ALTER TABLE ADD COLUMN [BEFORE,AFTER] column.
Я писал об этом везде где можно, и на http://postgresmen.ru/ на форуме в пожеланиях на будущие релизы и разработчикам, но так никто даже не почесался.
Без BEFORE,AFTER уж очень неудобно при изменении структуры таблицы, нарушается вся логика следования колонок.
Может здесь кто-то услышит меня. ;-)
| | |
| |
| 3.6, Vitaly_loki (ok), 19:05, 25/08/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
>А еще добавили бы, как в mysql, возможность ALTER TABLE ADD COLUMN
>[BEFORE,AFTER] column.
>Я писал об этом везде где можно, и на http://postgresmen.ru/ на форуме
>в пожеланиях на будущие релизы и разработчикам, но так никто даже
>не почесался.
>Без BEFORE,AFTER уж очень неудобно при изменении структуры таблицы, нарушается вся логика
>следования колонок.
>Может здесь кто-то услышит меня. ;-)
что-то спорная полезность данной фичи на мое имхо
| | |
| |
| |
| 5.11, Jay (??), 19:48, 25/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> что-то спорная полезность данной фичи на мое имхо
>
>тогда вы не разрабатывали/поддерживали большие проекты.
>рекомендую ознакомиться:
>http://wiki.postgresql.org/wiki/Alter_column_position
1) 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, но тем не менее.
Собственно, я-то не против этой фичи, но ресурсы разработчиков я бы предпочел направить на более полезные задачи.
| | |
| |
| 6.13, Аноним (-), 19:54, 25/08/2009 [^] [^^] [^^^] [ответить]
| +/– | |
так я как раз и ратую, с точки зрения разработчика больших высоконагруженных распределенных систем, которые в дальнейшем приходится поддерживать и дорабатывать.
с точки зрения пользователя, эта, как и многое и многое вобще не важно, главное чтоб работало и выполняло свои задачи.
| | |
| |
| 7.33, F.Y. (?), 02:53, 26/08/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>так я как раз и ратую, с точки зрения разработчика больших высоконагруженных распределенных систем
100 к 1 - ты таких систем даже на картинках не видел :)
| | |
|
|
| 5.19, uZver (??), 23:08, 25/08/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> тогда вы не разрабатывали/поддерживали большие проекты.
эта фича нужна только для запросов содержащих в себе логическую бомбу. достаточно НЕ ПРИМЕНЯТЬ select * и все будет хорошо.
а за select * направлять на дообучение или увольнять за профнепригодность.
| | |
| |
| 6.25, Аноним (-), 23:31, 25/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
> эта фича нужна только для запросов содержащих в себе логическую бомбу. достаточно НЕ ПРИМЕНЯТЬ select * и все будет хорошо.
> а за select * направлять на дообучение или увольнять за профнепригодность.
глупости. при запросах select * все нормальные люди используют ассоциативные массивы, и как раз тут структура данных и следование столбцов играют маловажную роль.
так же использовать запросы select * в большинстве случаев не имеет смысла из-за падения скорости и увеличении трафика, для передачи лишних, не нужных данных.
| | |
|
|
|
| 3.8, Jay (??), 19:28, 25/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
Какая вам разница, как столбцы хранятся в базе?
Постройте в SELECT нужный порядок и забудьте уже про фактический порядок столбцов.
Это вам, в конце-концов, не dbf :)
| | |
| |
| 4.9, Vitaly_loki (ok), 19:37, 25/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
Вот потому я и сказал, что спорная эта фича
Дофига существует больших проектов на PgSQL , и ведь как то обходятся... В Select укажи нужный порядок и усё
И. кстати. я ERP системы на этой СуБД сопровождаю, допиливаю
| | |
| |
| 5.12, Аноним (-), 19:51, 25/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
прошу прощения, с вами лично не знаком, поэтому судить не берусь о вашей компетенции, но как показывает моя практика наличие этой фичи очень сильно помогло бы многим разработчикам, в том числе и мне, т.к. не перевариваю, когда у меня таблицы со временем добавления других колонок теряют свою элегантность, а так же производительность и объем на диске.
я например, все fk размещаю в начале таблицы, а все varchar'ы и blob'ы в конце, а при вашем подходе будет каша.
сейчас же обходятся очень просто, читайте по этой ссылке на официальной wiki проекта, что я выше уже приводил:
http://wiki.postgresql.org/wiki/Alter_column_position
как вы рассуждаете, можно так же и о partitioning рассуждать, про который я выше написал и про master-master.
ведь как-то обходимся триггерами и кучей костылей.
хотя и радует, что из-за таких левых костылей появились такие замечательные проекты, как PL/Proxy.
| | |
| |
| 6.14, Аноним (-), 21:05, 25/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
Порядок столбцов это костыль к реляционной теории.
Реляционные БД потому так и популярны (читай надежны, быстры, удобны), что базируются на теоретической основе.
Поэтому разработчики во первы 10раз подумают над этим, во вторых сделают когда нечем будет заняться.
| | |
| |
| 7.15, Аноним (-), 22:17, 25/08/2009 [^] [^^] [^^^] [ответить]
| +/– | |
а вы, простите, разработчик, чтоб за них говорить? я все же надеюсь, что этот вопрос будет решен в ближайшее время, иначе так и будем писать левые костыли для переноса данных между старыми и новыми структурами данных и терять драгоценное время разработчиков в погоне за идеальной структурой.
структура и порядок столбцов важна, хотя бы для того, чтобы оптимизировать хранения данных на диске и скорость доступа к ним. об этом я и многие другие писали неоднократно.
что касаемо реляционных бд, то они популярны только из-за того, что на данный момент ничего удобней нет, а во всем остальном, они не надежны, не быстры и не удобны для большинство более менее серьезных задач.
| | |
| |
| 8.31, vitek (??), 01:31, 26/08/2009 [^] [^^] [^^^] [ответить] | +/– | структура, порядок, секционирование, индексирование - задача дба каждая бд ... текст свёрнут, показать | | |
|
|
|
|
| 4.10, Аноним (-), 19:38, 25/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
все должно быть идеально, начиная от проектирования структуры бд и заканчивая разработкой.
если у вас не проект, а каша, то со временем, время, затраченное на поддержку может возрасти в разы. каша в коде = каша в голове.
так же от правильно выбранной структура размещения колонок можно увеличить производительность и уменьшить объем базы.
| | |
| |
| 5.16, Аноним (-), 22:21, 25/08/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Если таблица про существовала скажем год, и вдруг понадобилось добавить колонку без удаления имеющихся данных. С какой такой радости нужно физически двигать имеющиеся данные в соответствии с новой структурой?
Это все равно что сделать совершенно новую таблицу, скопировать данные туда, старую удалить, новую переименовать.
Облегчение жизни для использования запросов типа select * from t; вообще не аргумент. Можно создать специальный View, в конце концов, с нужным порядком столбцов.
| | |
| |
| 6.17, Аноним (-), 22:29, 25/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
скопировать туда-сюда - так и работаем сейчас, вместо того, чтобы выполнить одну команду, которая сама на уровне субд сделает за нас всю работу, как это сделано в mysql.
а если на этой таблице навешано куча триггеров и она еще является partitioning таблицей, и на нее еще ссылается куча foreign key и еще куча всего, что реально используется в больших задачах, а не на сайтах за 5 копеек, что тогда делать?
| | |
| |
| |
| 8.22, Аноним (-), 23:24, 25/08/2009 [^] [^^] [^^^] [ответить] | +/– | нет времени на поиски если интересно можете организовать сами тестирование и на... текст свёрнут, показать | | |
|
| 7.20, uZver (??), 23:10, 25/08/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> а если на этой таблице навешано куча триггеров и она еще является partitioning таблицей, и на нее еще ссылается куча foreign key и еще куча всего, что реально используется в больших задачах, а не на сайтах за 5 копеек, что тогда делать?
отказаться от select * и применять select pk, fk1, fk2, fk3
| | |
| |
| 8.24, Аноним (-), 23:26, 25/08/2009 [^] [^^] [^^^] [ответить] | +/– | а никто и не использует select , т к тянуть за собой данные, не нужные в запро... текст свёрнут, показать | | |
|
| 7.34, vitek (??), 03:04, 26/08/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>скопировать туда-сюда - так и работаем сейчас, вместо того, чтобы выполнить одну команду, которая сама на уровне субд сделает за нас всю работу, как это сделано в mysql.
создайте уже пару-тройку хранимых процедур для автоматизации данного процесса.
а то не солидно как-то... для конторы не за 5 копеек.
>а если на этой таблице навешано куча триггеров и она еще является partitioning таблицей, и на нее еще ссылается куча foreign key и еще куча всего, что реально используется в больших задачах, а не на сайтах за 5 копеек, что тогда делать?
а не за 5 копеек принято пользоваться средствами, которые и умл-диаграммы строят, и скрипты генерят,.. а ежели в хороших руках, то ещё и с комментами и генерацией доков.....
в результате - всё тоже (отключить триггеры, перестроить индексы,.. что там ещё?) должна будет проделать эта команда. а если ещё б/д хранит данные не так просто как майисам (количество таблиц по количеству файлов б/д можно посчитать :-D), то ещё и данные подвигать туда сюда, екстенты добавить/убавить/оптимизировать (ведь не только имя в середину вставляется? это же не вьюха какая-нибудь, не так ли?)... и всё это сопровождается перманентными глюками и багами в особо сложных случаях.
нет уж! генерите скриптами, с комментами, со ссылками на номер бага/фичи и чтоб потом не тормозили запросы (когда каждая строка по всему винту размазана тонким слоем) и т.д. если это так важно клиентам конторы > 5 копеек.
а при разработке - вообще параллельно как там что храниться. лишь бы готовый скрипт генерации б/д был правильный.
| | |
| |
| |
| 9.36, vitek (??), 01:19, 27/08/2009 [^] [^^] [^^^] [ответить] | +/– | ВАШ слоник -DDDDDDDDDDDDDDDDDDDDDDD ну так держите его при себе читаешь плохо... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 1.4, white_raven (?), 17:37, 25/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 "Лучше бы допилили partitioning с нормальными индексами и без того изврата, что есть сейчас при добавлении/удалении записей с использованием тригеров."
Присоединяюсь
| | |
|
