libdbi - первый публичный релиз

Оху... пардон, ОФИГИТЕЛЬНО!
Интересно, у кого нить рука поднимется обкакать эту либу?

Ну!!! А по чему сразу и обгадить?
Мне она к стати понравилась. Как раз вовремя.
А то продавать проги на перле не правильно.

JDBC -> С ? Наверно не совсем удобно работать с BLOB.

А что за слово такое - "плугин"? :-)

2Defender. А она разве не GPL и если да, то как продавать???

2Korwin Новость бы прочитал. Она под LGPL.

Nu horosho -- govno eta liba. Vernee ideya.

Opjat lamery budut rozhat zhirnyx urodov.

Nelzya ispolzovat vse vozmoghnosti "rodnyh" API i nikakoi polzy vzamen.

Хмм... Ничего утверждать не буду, но, вроде бы есть ODBC :))) Вроде, даже, как стандарт :))

есть SqlAPI, там баз поболе поддерживается.

То С ODBC гемор иметь, то с JDBC, теперь еще и это... Доступа к базам лучше родного API нет и не будет (ну, возможно будет, но не скоро)! Perl вещь хорошая для DML команд, да и то над ним еще работать и работать. Согласен, что идея говно. Не надо "унифицировать" подход к базам данных. Ведь они различаются не ценой и фирмой-производителем, а возможностями, в них заложенными. Чаще всего при "универсальном подходе" встречаешься с тем, что программисты пишут (и успешно используют!) базы типа Oracle или DB/2 в режиме MySQL и 9/10 возможностей этих баз вообще не знают!...

А что за слово такое - "плугин"? :-)

Это как "сетуп";-)

Никто не спорит, что родной API быстрее, надежнее, больше возможностей. Но такие вещи как ODBC позволяют писать переносимые программы, когда программа работает вне зависимости от базы данных, а всяческие вкусности отдельных экземпляров, мне кажется, стоит прятать при проектировке самой базы, чтобы максимально облегчить жизнь программерам.Тогда и шашечки будут использоваться и выглядеть это будет достаточно просто.
Кроме того, приложения, работающие с базами данных бОльшую часть времени проводят в ожидании результатов запросов в самой базе данных, поэтому супер-пупер легкое оптимизированное под что-то конкретное родное API преимуществ практически не дает. Зато при переносы на другую базу данных приложение придется фактически переписывать.
Это мое личное мнение и с ним можно не соглашаться.

Кстати, о возможностях баз данных, используемых програмистами - можно использовать 90% возможностей баз данных используя сравнительно простые средства. Слишком непереносимые вещи можно заменить вызовом хранимых процедур или триггерами, что практически все базы данных умеют. И появление специфических запросов в самой программе мне кажется следствием неправильного проектирования структуры базы.

Опять же - это мое личное мнение. Товарищи с большим опытом работы поправьте меня, пожалуйста, если я не прав.

2evil "Но такие вещи как ODBC позволяют писать переносимые программы, когда программа работает вне зависимости от базы данных" Переносимую откуда куда? С Виндов на винды? "а всяческие вкусности отдельных экземпляров, мне кажется, стоит прятать при проектировке самой базы, чтобы максимально облегчить жизнь программерам" Т.е. проектировать-то ее надо через родной API все-таки! "Кроме того, приложения, работающие с базами данных бОльшую часть времени проводят в ожидании результатов запросов в самой базе данных, поэтому супер-пупер легкое оптимизированное под что-то конкретное родное API преимуществ практически не дает. Зато при переносы на другую базу данных приложение придется фактически переписывать" С этим полностью согласен! "Большая и серьезная" база еще тот тормоз! Но опять же что и куда преносить? Из MySQL или Postgres например в Oracle, MSSQL, DB2, Informix прернести как-нибудь можно (да и то только данные). Но вот наоборот ну никак не получится. Придется действительно все переписывать заново. Более того - так и надо делать! "Кстати, о возможностях баз данных, используемых програмистами - можно использовать 90% возможностей баз данных используя сравнительно простые средства" Какие, например? У них даже синтаксис SQL'я и типы данных разные :-(( "Слишком непереносимые вещи можно заменить вызовом хранимых процедур или триггерами, что практически все базы данных умеют. И появление специфических запросов в самой программе мне кажется следствием неправильного проектирования структуры базы" Вот-вот, спроектировать базу а-ля msql и пользоваться ею везде! Да набор типов объектов в разных базах как небо от земли отличается. Все фичи опять же побоку?

2anonymous (*) (2001-08-08 14:34:12.0)

Знаешь, я, пожалуй, скорее, соглашусь с evil'oм. Видишь ли, есть такая штука, как стандарт. Какой там сейчас? SQL3? Ну, на SQL2 и остановись. А все нестандартные фичи лучше располагать в процедурах, триггерах и т.д. Меньше гемороя потом будет. Процедуры перепишешь, и все. Синтаксис SQL у нормальных баз данных один. Не путай с SPL. Проектируются, кстати, базы (среди нормальных разработчиков) на логическом, а не на физическоим уровне, поэтому пересоздание схемы на новом движке занимает не больше, чем требуется дя нажатия на одну кнопку. А насчет наборов данных -- читай стандарт, и помни, что все остальное -- от лукового. Того, что там есть, хватает с избытком.

от anonymous (*) (2001-08-08 11:17:10.0)&anonymous (*) (2001-08-08 14:34:12.0) to anonymous (*) (2001-08-08 15:11:24.0)

Да я и не спорю. Все так и должно быть "в идеале". Вопрос в другом - как есть сейчас? SQL3 хорошо, SQL2 тоже неплохо (есть еще ANSI, ISO, FIPS). Равнение на IBM (благо им в этом вопросе доверять можно). Но некоторые мелкие фирмочки, типа Oracle, кладут на них и делают свои расширения (притом значительные). Я не знаю - сатанисты они или нет, но изрядную долю рынка они оттяпали. Проектирование базы на логическом уровне - это один из этапов. "Нормальные разработчики" - вообще в отрыве от платформы RDBMS базы проектируют и это правильно. Но есть другой этап - "черезколенное запихивание ER диаграмм на сервер". И вот тут уже важен SQL платформозависимый. Если пересоздание базы выполняется одной кнопкой, то зачем тогда нужны DataJoiner (IBM DB/2), Oracle Transparent Gateways (Oracle)? Отнюдь не маленькие продукты. Они из какого стандарта в какой переводят? Нет одной кнопочкой не обойтись. А вообще хочется, конечно иметь тулзу ПОД ВСЕ базы, Чтобы она еще не сильно отставала (по времени) от разработчиков RDBMS. Чтобы все поизводители договорились о едином стандарте, чтобы был мир во всем мире...
Лично я дожить до этого не планирую.

А часто ли надо будет переносить с одного engina на другой, если база была спроектирована правильно, движок был подобран так, что его хватит до потолка (ну не будут же поначалу всякую промышленную херню (это на значит, что все промышленное - херня) делать на MySQL ;)

А что, Оракле маленькая конторка?

2cornholio

В общем-то нечасто, но ситуации всякие бывают, и унаследованные системы -- тоже. Иногда миграция с одной версии движка на другой тоже еще тот геморрой. Но речь-то, собственно, не об этом, а о том, что иметь достачтно высокий уровень абстракции для _доступа_ к данным - не так плохо. А то получается та же фигня, что и у PHP, в которой, сейчас, да, появился, некий abstraction layer, но не для всего, а так все это приходится делать руками, что лично меня совсем не устраивает. Кстати, upsizing -- не такая уж и редкая вещь. Наконец, просто случается так, что надо гонять данные между несколькими базами на разных движках, и вот тут-то вещи типа ODBC, JDBC, DBI, DB-API и что там еще есть весьма и весьма к месту.

Это хорошо. Стандарт - это просто здорово. Нет, действительно люблю. На оформление кода программ например. Или имена переменных.
А сообщество в курсе что у Сайбейз и MS представление о генерации значения identity сильно отличается от оракловой генерации через sequence? И что у Cайбейз Adaptive Anywhere генерит значения для тех же суррогатных первичных ключей нет так, как это делает их же enterprise сервер (а все Watcom-собака. И куда делся? Кто за все это отвечать будет?). А потом Borland пытется единообразно лепить совершенно гениальные live query над всем этим. И обгаживается, само собой. Привет, так же оракловым объектам. Им правда и так привет, но все же... Про сайбейзовскую Яву говорить не приходится.
А про то, что база проектируется без учета физической реализации - это я сейчас своему приятелю-оракловому админу расскажу, он будет немного смеяться. ER - диаграммы вообще прямого отношения к СУБД не имеют. Но потом-то, бляха муха, приходится к физической модели переходить. Погоняйте модель в ERWin'e из СУБД в СУБД и посмотрите на типы данных в физическом представлении. Те, кому особенно интересно могут сравнить понятия index organized table у оракла и кластерный индекс у Сайбейз или MS и что из этого проистекает в смысле индексирования от которого рукой подать до животноводческого понятия "покрытие индексом". Или подумает в процессе проектирования "без учета физической реализации", как заменить оракловый partitioned table в Сайбез, что бы запросы после года эксплуатации все-таки отвечали за приличное время.

Полуденный Бес

Господа, переносимые приложения не миф, а реальность, к которой некоторые личности стремятся. Я лучше не буду использовать специфичные фичи, но буду жить спокойно сегодня и завтра. Все равно правильность алгоритмов решает больше, чем оптимизация различных вещей в базах данных, компиляторах. Через год производительность компьютеров поднимется и мои приложения(в идеале) будут работать как ваши сегодня за те же деньги(закон Мура), зато мне не нужно будет переписывать приложение из-за того, что продукт решили перенести на другую платформу/базу данных. Лучше потратить время на изучение алгоритмов решения задачи, чем на специфические фичи конкретной базы данных. Если алгоритм хреновый, то никакие оптимизации не помогут.
У меня еще слишком мало опыта и я буду рад, если кто-то меня поправит.
С уважением, Максим Мороз.

2ALL Стандарт нужен. Однозначно. Это ясно всем. Но он нужен не для всех приложений... Приведу два примера: CGI-приложение и офисный пакет.
В CGI если ДБ спроектирована корректно и код написан правильно лучше использовать нативный API и скорость и переносимость особа не нужна.
В примере с офисным пакетом именно нужна независимость от нативного API (ODBC например). Чтобы была простая возможность использовать _любую_ ДБ для генерации тех же писем, конвертов, отчетов и т.д. Здесь без Стандарта не обойтись. Скорость и фишки уже не так важны.

По поводу проектирования ДБ без опоры на физическую реализацию. Все верно.
Как должна проектироваться ДБ:
1. Логическое проектирование базы данных и нормализация.
1.1. Моделирование взаимосвязей между объектами (тип данных не важен сейчас). Наиболее популярный метод - методика диаграмм взаимосвязей между объектами предложенная в 1976г. П.П. Ченом (Entity-Relationship Diagramm - ERD)
1.2. Преобразование ERD в реляционную модель. Поскольку пока ДБ имеют реляционную модель (ну уже не все. Есть постреляционные, объектные и т.д., но сейчас это пока только надстройки).
1.3. Нормализация.
1.3.1. Обеспечение целостности.
1.3.2. Создание формальной модели, как можно более _независимой_от_специфики_приложения_.
1.3.3. Снижение требований к объему памяти.
Следует отметить, что номализация проходит по нормализованным формам Бойса-Кодда - отсутствие инверсной частичной зависимости.
Чаще всего используется только 3 формы и этого достаточно в большинстве случаев. Седьмая и восмая нормальные формы встречались пока только в диссертациях, но не на практике.

И только потом идет _физическое_ проектирование баз данных и _технические_ средства. При физическом проектировании учитывается не только необходимые возможности ДБ, но и определяются требования к железу.
2. Физическое проектирование.
2.1. Определение типа приложения.
- Оперативная обработка транзакций (OLTP)
- Системы поддержки принятия решений (DSS)
- Пакетные системы.
- Системы оперативного адализа (OLAP)
- БД с переменной структурой (VCDB)
2.2. Использование количественных оценок
- Количество параллельно работающих транзакций
- Время реакции системы
- время обработки
- количество транзакций
- количество параллельно выполняемых программ
- количество считанных или записанных байтов
Типичный набор параметров включает три значения (минимальное, среднее и максимальное).
2.3. Анализ объемов
2.4. Анализ роста ДБ
2.5. Денормализация
2.6. Иерархия запоминающих устройств
2.7. Узкие места СУБД
2.7. Выбор платформы
2.8. И прочие чисто технические вещи.


2{Полуденный Бес} {А про то, что база проектируется без учета физической реализации - это я сейчас своему приятелю-оракловому админу расскажу, он будет немного смеяться} Тут надо не смеяться, а плакать над таким админом когда приходиться его переделки переделывать, а часто это оказывается просто невозможным. Нормально спроектированная ДБ на PostgreSQL работает надежнее и быстрее чем плохо спроектированная на Oracle и это, думаю, ни для кого не секрет.
Так что надо твоему приятелю подучить теорию чтобы не облажаться в один прекрасный момент по крупному.
Извени, но это не наезд. Просто мысли в слух.

2{Максим Мороз} В принципе ты говоришь верно, но в больших проектах соблазн использовать фишки ДБ... И их надо использовать, но с умом. Простой пример: Одна ДБ и туева куча различных клиентов. Что лучше сделать проверку целостности данных средствами ДБ (тригерры и т.д.) или делать это в каждом клиенте? А если в одном клиенте произойдет логический сбой? Все данные потеряют целостность... Как ты думаешь, что будет с администратором этой ДБ?

Уважаемый Korwin, я с большим удовольствием прочитал ваши замечанию, в свою очередь у меня возникли просьбы и уточнения.
Сначала хотелось бы уточнить свою позицию:
По поводу использования фишек конкретной ДБ - специфические фишки не входящие в стандарт нужно изолировать посредством хранимых процедур. Это мое мнение. Фишки эти иногда очень помогают, но иногда детали заслоняют главное. Ровняться нужно на стандарт. Не слепо следовать ему, но придерживаться так точно нужно.
По поводу целостности данных - если не ошибаюсь, внешние ключи описаны в каком-то из стандартов SQL и являются вполне обыденной и жизненно необходимой вещью. Сейчас не начало 90-х и если БД не поддерживает их, то ее лучше заменить(хотя есть задачи, где это не важно :)) Mysql рулит :)))))))))))))) ).
По поводу сбоев в приложениях, то полагаю, использование транзакций, которые, опять же, не являются непереносимыми и редкими фишками, помогает в таких случаях. Более того, поддержка транзакций может играть решающую роль при выборе базы данных для конкретной задачи.
По поводу гипотетического администратора БД... Если бы я был на его месте, то обоснованно бы заметил, что вешать за интимные места нужно разработчика БД и автора ТЗ. :))))) Или того, кто все это решение принимал в эксплуатацию :)))

Теперь у меня есть просьба: не могли бы вы посоветовать литературу(можно в Интернете) по теме проектирование баз данных.
В частности вы упомянули ERD и нормализованные формы Бойса-Кодда.
К моему стыду я не имею представления о данных вещах и прошу указать мне, где искать, т.к. проектированием баз данных заниматься приходится, мне это интересно, но дилетантом оставаться не хочется.

Народ, ну что вы спорите?! Ну что мало разве задач, которым нужда просто база данных... для хранения и выборки, дабы не писать собственных монстроподобных db? Ну календари, планировщики, записнушки, телефонные справочники - разве мало такого добра? И представьте как будет удобно, когда не придется каждую из этих фитюлечек переделывать на API очередной БД. И не придется говорить, что для работы нам бы хотелось видеть MySQL у вас, а не этот Oracle, который у вас все равно уже стоит...

RSM

Фигли "с виндов на винды"? Есть же UnixODBC. И про невозможность переноса с Oracle на Postgres лучше не гнать. Вполне реально, и переписывать ничего не требуется (однако JDBC забинденный в Kawa пользую - рулез отменнейший).

Oracle... MySQL... Informix! Вот где мысль программистская повеселилась(я сейчас второй курс по информиксу прохожу)! Нормально писать хранимые процедуры можно тока на Цэ (теоретически, можно на java,... не знаю, мне вряд ли понадобится), родной SPL тормоз и не всё на нём можно писать. Зато можно использовать opaque types -- чёрные ящики, суть объекты. Да-да, на логическом уровне мы можем игнорировать существование объектов, таблиц и ваще баз данных, но когда говорят о переносимости, собираются переносить не логическое представление, а реализацию. И тут можно утрахаться вусмерть. Перенесите мне opaque types на MySQL, plz... Гы, забудьте и MySQL и вообще базы данных, если хотите переносимости. Переносимость в мире баз данных тока на уровне select * from table, выше -- нет. Пример: выбрать первые десять элементов из таблицы:

Oracle: select * from table where rownum < 10;

Informix: select first 10 * from table;

Будет ваша libdbi парсить мой стэйтмент и приводить его в соответствие с базой данных? Не верю.

fu-ty, gspdi. O kakom "standarte" idet rech? Prichem tyt SQL92, SQL93?

Rassmatrivaetsya uroven' CLI (CALL LEVEL INTERFACE) -- prichem SQL? Prichem "spryatat v protsedury" -- esli libdbi (ODBC i proch.) otvechaut za _sposb vyzova_ etih procedur.

Blin, srazu vidno, chto vyroslo pokolenie ponyztie ne imeeushie o "native API".

Von oracle umeee odnim "fetch'em" vydergivat proizvolnoe kol-vo zapisey. Chto resko snizhaet setevoi traffic. Interbase umeet vozvrashat iz procedur cursory, NW SQL peremeschatsja po kursoru v obe storony (a debilnyi ODBC kesheruet ego na kliente), tot ghe oracle vozvrashaet tablitsy is procedur. I chto? Vse idet pod nogh radi lamerov kotorye nikak ne mogut reshitsa kakuu bazu polzovat.

Ugh esli nughna perenosimost' to obespechivatsa ona dolghna na urovne samogo prilogenya:

PostgreSQL -> tolstyi-tolstyi sloi Scheme - > Scheme Oracle -> PL/SQL -> nemnoghko Scheme -

Zdes "Scheme" -- dialect Lisp'a.

Analogichnyi podhod -- SAP/R3

Koroche -- "zatychku" proche perepisat pod konkretnui bazu -- vse ravno vremya zhizni tackih zadach minimalno. Ser'eznye zadachi trebuut ser'eznogo produmyvania.

I ghm. Komu udalos bezboleznenno perepolzti s Paradox'a na Oracle s pomoschiu BDE? :) Kakie vpechatlenia ot etoi _popytki_ pozanimatsa sex'om s "perenosimostiu"? Nepravda li popahivaet impotetstiei?

2Casus: а зачем вам собственно выбирать первые 10 строк из таблицы? Они же неупорядоченно хранятся, смысл имеет только с ORDER BY юзать, а он везде одинаков :-)

2 Korvin

Тот админ, о котором я говорил, сам вполне способен преподавать теорию. Кроме того, в издательстве O'Relly выходила книжка, названия я точно не вспомню, что-то вроде "Проектирование баз данных Oracle". Думаю, не лапух ее писал. Так вот, там говориться, что админ должен принимать участие в разработке БД. И приводятся аргументы в пользу этого. Самый простой из них - админ знает о производительности СУБД больше, чем любой разработчик. В противном случае или админ плохой, либо разработчик не своим делом занимается. О pctfree должен админ заботиться.
А с тем, что кривая база на Oracle хуже, чем прямая на PostgreSQL трудно не согласиться. Хотя и здесь возможны варианты, с PostgreSQL не работал.
"Следует отметить, что номализация проходит по нормализованным формам Бойса-Кодда" - зачем так котегорично? Я бы даже сказал, что большие базы, в смысле количества таблиц (или базовых отношений, если быть академичным) иной раз приходиться уродовать до той степени денормализации, дальше которых только "нулевая" нормальная форма, ее чаще всего достигнуть не удастся (атомарность атрибутов отношения обычно прошита в физической реализации СУБД, хотя, с другой стороны, есть и Progress, и embeded tables в Оракле и явские объекты в полях Sybase). И все в угоду производительности, обычно все-таки этот паказатель во главе угла, хотя жизнь разнообразна и удивительна.

2 evil
Поищи К.Дж.Дейта названия опят-таки точно не помню,кажется "Введение в системы баз данных". Фундаментальный труд, высокая теория. Там про нормальную форму Бойса - Кодда все написано, равно как и про остальные нормальные формы. Только учти, что на практике реляционная теория обычно остается за бортом. И никакой нармальной формой Бойса - Кодда там не пахнет. Особенно, когда речь идет о хранилище данных.
И насчет алгоритмов. Фраза, выстраданная годами трудов на поприще работы с базами, потом и кровью: большая задача решается ТОЛЬКО НА СТРУКТУРЕ ДАННЫХ. Все. Алгоритмы ничего не стоят в БОЛЬШОЙ ЗАДАЧЕ. А структуры данных - это как раз "специфические фичи".

Полуденный Бес

2 anonymous (*) (2001-08-09 10:25:04.0)

"а зачем вам собственно выбирать первые 10 строк из таблицы? Они же неупорядоченно хранятся, смысл имеет только с ORDER BY юзать, а он везде одинаков" - иес. Пресловутая реляционная теория глаголит, что картежи хранятся неупорядоченно. Но если сделать select *
из таблицы имеющий первичный ключ, то выборка будет упорядоченной в порядке возрастания значений первичного ключа, если он есть (это правда СУБД - зависимая штука, но я другого что-то не припомню). Так что rownum < 10 - иной раз очень в жилу.

Полуденный Бес

2casus:

Я не уверен, но возможно в этой либе твой запрос к Информиксу будет
выглядеть так:

result = dbi_driver_query(driver, "select first %u * from table", 10);

когда появится plugin для информикса ;)

2 alman
А как будет выглядеть такая заява в плагине для Oracle (прямо из демо дернул):
-- Сначала, для наглядности
CREATE TYPE num_varray AS VARRAY(10) OF NUMBER(12, 2)");
CREATE TABLE varray_table (col1 num_varray);
INSERT INTO varray_table VALUES (num_varray(100, 200));
--и далее
SELECT * FROM varray_table

Как мне разбираться с результатом посреди стандарта? Не-е-е.. братцы - программы программировать - дело ручное, тонкое.

Полуденный Бес

2 Полуденный Бес:

По-видимому такой запрос с помощью это либы сделать нельзя.
Дык, каждой задаче свое решение.
RSM хорошо высказался выше.

2 alman

RSM совершенно прав. Но он перечислил области применения, которые уже паханы - перепаханы, и программного обеспечения на эту тему - мульен. Я имею ввиду то, что там писать ничего не надо. Мы же здесь орлы по всем статьям? И ничего тривиального писать не будем? Мне вот психика не позволяет многократно повторяться - пальцы слабеют и мысли путаются.

Полуденный Бес

2Полуденный Бес: > "Но если сделать select * из таблицы имеющий первичный ключ, то выборка будет упорядоченной в порядке возрастания значений первичного ключа, если он есть (это правда СУБД - зависимая штука, но я другого что-то не припомню)."

Не, это неправда :-) Чем с точки зрения оператора SELECT поле первичного ключа отличается от других? В постгресе скажем записи хранятся в порядке добавления/изменения (свежий - в конце), никакой связи с первичными ключами нет...

> " Так что rownum < 10 - иной раз очень в жилу."

Таки не понял, зачем вам строки с десятью наименьшими значениями первичного ключа? Как правило, ключ в себе полезной для пользователя информации не несет, а даже если и несет (скажем UID пользователя), то такая выборка крайне редко потребуется - как правило ее юзают те, кому лениво поле даты ввести в таблицу, что не есть гуд в плане проектирования. Вообще мое имхо состоит в том, что ключи должны использоваться только для связи таблиц, а осмысленное наполнение - это другие поля пусть будут.

2 anonymous (*) (2001-08-09 16:00:37.0)

"Не, это неправда :-)"

Я не сказал, что ОБЯЗАТЕЛЬНО так будет. Это результат наблюдения за "дикими гусями". С точки зрения SELECT'a - да, наплевать, какой там у них первичный ключ и есть ли он вообще. А вот с точки зрения реализации этого SELECT'a видимо нет. Скорее всего это получается из-за того, что первичным ключом обычно служит член возрастающей последовательности натуральных чисел. И чем позже вставлена запись, тем больше у нее это значение. Понятно, что и хранится на физическом уровне она должна где-то "на хуторе". Поэтому при неупорядоченной выборке (кстати, такое невозможно, как-то СУБД должна ее упорядочить в любом случае. Иначе как работать с курсором построенным на "select * from table1". Просто это упорядочивание скрыто от пользователя. Oracle такие выборки упорядочивает по rowid). Но я еще раз повторю, что это НЕ ПРАВИЛО и полагаться на него нельзя.

"Таки не понял, зачем вам строки с десятью наименьшими значениями первичного ключа?" - необязательно наименьшие в таблице, наименьшие в выборке. Кто мне мешает добавить WHERE? А вот зачем?.. Э-э-э...

А-а-а-а!!! Придумал! Некая фирма хочет всучить приз первым десяти покупателям ее барахла, зарегистрированным в марте 2001 года. Астрономическое время регистрации у бакланов в базе не храниться, но первичный ключ генерится, как ни странно, по-человечески. Во! Уел я тебя?

"... ключи должны использоваться только для связи таблиц, а осмысленное наполнение - это другие поля пусть будут.
" - иес. Это не только твое мнение, но мое и многих других: первичный ключ должен быть либо суррогатным, либо вообще отсутствовать. Можно даже основать Ассоциацию Защитников Первичных Ключей с правом ношения автоматического оружия. А то иной раз лезешь в чужую базу, а там первичный ключ состоит из имени+фимилии+отчества. Или артикула товара. Гражданства надо лишать за такие дела.

Полуденный Бес

2Полуденный Бес:

> "Поэтому при неупорядоченной выборке (кстати, такое невозможно, как-то СУБД должна ее упорядочить в любом случае."

Да как лежит, так и берет ;-))

> "Просто это упорядочивание скрыто от пользователя. Oracle такие выборки упорядочивает по rowid"

Я думаю, что если такое скрытое упорядочивание существует, то вызвано оно побочными факторами, например, навешенным на поле ключа индексом.

> ""Таки не понял, зачем вам строки с десятью наименьшими значениями первичного ключа?" - необязательно наименьшие в таблице, наименьшие в выборке. Кто мне мешает добавить WHERE?"

Ну... не суть важно.. WHERE от таблицы есть тоже таблица.

> "Некая фирма хочет всучить приз первым десяти покупателям ее барахла, зарегистрированным в марте 2001 года. Астрономическое время регистрации у бакланов в базе не храниться, но первичный ключ генерится, как ни странно, по-человечески. Во! Уел я тебя?"

Дык о чем я и говорил - лень и кривое проектирование :-) При разработке структуры базы закладываться на определенный механизм генерации ключа как-то сомнительно.. Миграцию вряд ли перенесет :-) А так - тока для рандомных выборок разве что хорошо :)) И то хреновый рандом - и не знаешь что достанешь, и в то же время перемешано плохо :-))

2Evil. На счет литературы. Зайди на www.ozon.ru или любой другой. Искать: 1. (на мой взгляд очень good). Томас Коннолли, Каролин Бегг, Анна Страчан. Базы данных. Проектирование, реализация и сопровождение. Теория и практика (Database Systems. A Practical Approach to Design, Implementation, and Management)

2. Дейв Энсор, Йен Стивенсон. Oracle. Проектирование баз данных

3. Джеффри Д. Ульман, Дженнифер Уидом . Введение в системы баз данных

2Полуденный Бес. {Так вот, там говориться, что админ должен принимать участие в разработке БД. И приводятся аргументы в пользу этого. Самый простой из них - админ знает о производительности СУБД больше, чем любой разработчик.} если вы внимательно читали мой постинг, то увидели что админ принимает участие, но, в основном, при физическом проектировании. {Только учти, что на практике реляционная теория обычно остается за бортом. И никакой нармальной формой Бойса - Кодда там не пахнет.} ну за чем же так категорично. Мне однажды в руки попалась ДБ в фирме он-лайн магазина с 2 таблицами. В одной из них было 98 столбцов... Дальше про нее говорить не буду. Ваша выстраданная ФРАЗА... Я полностью солидарен с Вами, но эта Структура должна быть как можно лучше сделанной. Иначе геморой на всю жизнь, а для этого надо знать теорию.

Твой пример с rownum народ не очень корректно понял. На самом деле выбираются первые 10 _несортированных_ значений насколько я помню. Т.е. SELECT refnum, name FROM user WHERE refnum < 3; 1 Alex 2 Masha

SELECT refnum, name FROM user WHERE refnum < 3 ORDER BY name; 14 Aakmulat 14532 Abrik

Выгода от такого запроса очень, очень маленькая :-)

К вопросу о механизме генерации ключа в примере с фирмой и "астрономическими ключами". А что делать если в следующей версии ДБ этот механизм изменится?

Предыдущий постинг не так отобразился. Вот что хотел написать:
SELECT refnum, name FROM user WHERE refnum < 3; 
1 Alex 
2 Masha 

SELECT refnum, name FROM user WHERE refnum < 3 ORDER BY name; 
1423  Aakmulat 
145   Abrik

при этом первый столбец это не индекс! а просто номер строки в выборке.

Спасибо, Korwin, очень признателен. Если бы все треды на этом сайте были бы такими полезными :(
Книжек уже заказал :) Все-таки Ленин был прав :)))))))))))))))))

Не, народы, не сечёте фишку. Если у нас нет специального нумеровочного поля в таблице, то в Oracle его фукцию исполнят псевдополе rownum, в Informix такого нет, но у них есть слегка изменённый синтаксис для таких запросов. order by никто не отменял, будут у нас данные упорядочены как надо. Но это ещё не всё, в Informix можно делать select middle <n> ... вот так-то! Переносимость, блин... 2alman: Речь шла о том, что писаное с использованием libdbi сможет работать с любым sql-server'ом. Я говорю, что не будет, поскольку сами sql-сервера не согласны с тем что же такое sql есть. А наблюдая как у нас ведётся разработка и как все морду воротят от реляционной модели (у нас используется смешанная объектно-реляционная модель) я вообще не думаю, что что-нибудь серьёзное имеет смысл перетаскивать по разным sql-серверам. Вывод: сомнительна полезность этой библиотеки.

Не так выразился: в сомнительном направлении хотят эту библиотеку развивать.

2Casus
>Informix! Вот где мысль программистская
>повеселилась(я сейчас второй курс по информиксу прохожу)!
>Нормально писать хранимые процедуры можно тока на Цэ

Убей своего преподавателя. Можно писать хранимые процедуры на SPL, и
даже довольно быстро работают. Этот как бы не по вторым курсам, а по
опыту совершенно реальной работы говорю. И, кстати, есть еще 4GL, в
том числе и Dynamic.

Да, а всякие там FIRST, TOP и так далее -- прости, но это костыли, а
они у всех разные, как и SPL.

2 Korvin

Говорить о выборке rownum < 10 уже не хочется, я думаю Вы поняли мою мысль, могу привести совершенно практический пример, в котором надо выполнить update таблицы с десятками миллионов записей. Такой update, естественно ни в какой сегмент отката не влезет, вот там подобный select все спасает. Но, как говорил мой знакомый "Задача творческая, а значит, может быть решена тысячью способов". Радикальное утверждение конечно, но доля правды в нем есть.

"Да как лежит, так и берет ;-)) " - естественно, а rowid что собой представляет? "Как лежит" и представляет.

"К вопросу о механизме генерации ключа в примере с фирмой и "астрономическими ключами"". А что делать если в следующей версии ДБ этот механизм изменится?" - я такого себе представить не могу. Представляете, сейчас Главный Oracle заявит: "Все, ребята, теперь никаких sequence в before insert триггерах! Sequnce вообще не будет, радуйтесь! Теперь identity будет, как у Sybase. Мы тут подумали, что так лучше. Никаких инсертов в это поле. Аминь!" От такого заявления полмира животом маятся будет, а вторая половина - головой. А астрономическое время я не в качестве PK имел ввиду.

"В одной из них было 98 столбцов... " - гы - гы! Это повезло, редкий экземпляр попался, я больше 74 не видел.

Полуденный Бес

2spectator: Opaque types ты на SPL смогёшь?

2Casus

Звиняйте, мы люди серые, на семерке сидим, а девятого под рукой нет, чтобы поэкспериментировать, но судя по родной документации к девятке никаких препятствий не наблюдается :) Ежли есть проблемы -- расскажи. Страсть как люблю об информиксе слушать (читать, то есть).

2spectator: Угу, нет поддержки -- нет проблемы ;-) opaque types и всё, что с ними связано, реализуется только через UDR, обещали C & Java, но Java в очень экспериментальном state, как я понял. 4gl может тоже как-нибудь пойдёт, не в курсе, мы этого зверя нигде не пользуем.

2Korvin & 2Полуденный Бес Так к слову-с. 98 столбцов или 74 это вы мало видели. Есть такая прога АРМ Декларанта. Ее чудо-программисты на Clippere писали, использовали DbBase III. Там в одной из таблиц было 564 столбца. (Вспомним нулевую или -1 нормальную форму :-). Необходимо было вытянуть коекакие данные оттуда. С таки количеством столбцов ODBC, и native drivers в MS Access отдыхали. Пришлось в Oracle портировать, во гемору было. :-)

Ник.