The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Есть ли будущее реляционных баз данных"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [ Отслеживать ]

"Есть ли будущее реляционных баз данных"  
Сообщение от opennews (ok) on 14-Фев-09, 15:17 
"Is the Relational Database Doomed? (http://www.readwriteweb.com/archives/is_the_relational_datab...)" - есть ли будущее у реляционных баз данных. Рассмотрены недостатки реляционной модели, представлены доступные сегодня альтернативы. Рассказано о бесструктурных БД вида ключ/значение, например, о  Amazon SimpleDB, Apache CouchDB (http://couchdb.apache.org/), Project Voldemort (http://project-voldemort.com/), Mongo (http://www.mongodb.org/) и Google BigTable.

URL: http://www.readwriteweb.com/archives/is_the_relational_datab...
Новость: https://www.opennet.ru/opennews/art.shtml?num=20276

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Есть ли будущее реляционных баз данных"  
Сообщение от Stanislaus email(ok) on 14-Фев-09, 15:17 
Странную альтернативу двигает автор... Не смотря на то, что в некоторых областях key/value databases действительно применимы, реляционную модель В БОЛЬШИНСТВЕ областей заменить сложно.

The responsibility of ensuring data integrity falls entirely to the application. API
Data is created, updated, deleted, and retrieved using API method calls.

Уже настораживает. А чем тогда мешает создать в postgreSQL одну таблицу и назвать ее доменом. Уже отсутствуют реляционные связи.

CREATE TYPE value_type AS (
maker text,
model texp,
price double presicion,
...
);

CREATE TABLE domain_one (
key bigserial,
value value_type
);

А теперь еще и кластеризуем с помощью plproxy.

Кроче, автор меня не убедил, что нужно отказываться от реляционных СУБД (подчеркиваю слово СУБД) в пользу реализации АПИ в приложении.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Есть ли будущее реляционных баз данных"  
Сообщение от geekkoo (ok) on 14-Фев-09, 19:45 
Угумс. Можно и так. Потом сравниваем скорости и убеждаемся, что постгрес проигрывет на порядки ...
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 15-Фев-09, 22:37 
>Угумс. Можно и так. Потом сравниваем скорости и убеждаемся, что постгрес проигрывет на порядки ...

При всем уважении к Постгрес и к ее инструментарию, в логической реализации реляционной модели в Постгрес допущена одна очень грубая концептуальная ошибка, что фактически сводит на "нет" реляционную алгебру в Постгрес.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

30. "Есть ли будущее реляционных баз данных"  
Сообщение от Arsenicum on 16-Фев-09, 11:14 
Какая ошибка?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

31. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 16-Фев-09, 11:21 
>Какая ошибка?

Ну вот, после всего сказанного (см. по номерам сообщений) наконец-то хоть кто-то задал этот вопрос.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

32. "Есть ли будущее реляционных баз данных"  
Сообщение от geekkoo (ok) on 16-Фев-09, 12:31 
>>Какая ошибка?
>
>Ну вот, после всего сказанного (см. по номерам сообщений) наконец-то хоть кто-то
>задал этот вопрос.

Задал-то он его задал, а вот получит ли ответ? Судя по моему предыдущему опыту - вряд-ли ...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

34. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 16-Фев-09, 12:42 
>Задал-то он его задал, а вот получит ли ответ? Судя по моему предыдущему опыту - вряд-ли ...

Вот именно вы, geekkoo, в отличии от некоторых, вполне способны найти этот ответ самостоятельно. Если он вас действительно интересует, конечно.


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

36. "Есть ли будущее реляционных баз данных"  
Сообщение от geekkoo (ok) on 16-Фев-09, 12:56 
>>Задал-то он его задал, а вот получит ли ответ? Судя по моему предыдущему опыту - вряд-ли ...
>
>Вот именно вы, geekkoo, в отличии от некоторых, вполне способны найти этот
>ответ самостоятельно. Если он вас действительно интересует, конечно.

Ну, вот, теперь меня же и назначили ответственным за всё происходящее безобразие ...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

33. "Есть ли будущее реляционных баз данных"  
Сообщение от Arsenicum on 16-Фев-09, 12:39 
>> Ну вот, после всего сказанного (см. по номерам сообщений) наконец-то хоть кто-то задал этот вопрос.

Ну вот, после всего сказанного вопрос остаётся в силе.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

35. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 16-Фев-09, 12:45 
>Ну вот, после всего сказанного вопрос остаётся в силе.

А я и не спорю, что это важный вопрос. Вы только подтвердили, что вопрос остается в силе.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

37. "Есть ли будущее у продавцов жабы"  
Сообщение от Andrey Mitrofanov on 16-Фев-09, 12:58 
>А я и не спорю, что это важный вопрос.

Шея не болит, о Великий?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Есть ли будущее реляционных баз данных"  
Сообщение от geekkoo (ok) on 14-Фев-09, 20:00 
>>Уже настораживает.

Что именно? Есть куча баз данных, которые работают в режиме - одно приложение, одна база. Какой тогда смысл дублировать проверку на целостность внутри сервера, если ее можно выполнить (а можно и не выполнять) на стороне приложения. И RDBMS за собой тянут ещё кучу подобного оверхеда, включая парсер SQL.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Есть ли будущее реляционных баз данных"  
Сообщение от vitek (??) on 15-Фев-09, 00:40 
>Что именно? Есть куча баз данных, которые работают в режиме - одно приложение, одна база. Какой тогда смысл дублировать проверку на целостность внутри сервера, если ее можно выполнить (а можно и не выполнять) на стороне приложения.

странное утверждение. особенно для много-пользовательской работы.
не говоря о том, что так называемая проверка на целостность обычно сопровождается индексами. или Вы какие-то другие приложения имели ввиду?
один пример - после перехода evolution на sqlite потребление ОЗУ сократилось в трое, а скорость работы увеличилась. да и вообще, использование встраиваемых sql приложениями заметно выросло.
>Т.е. это хорошо заметно - решая более общий случай, получаешь потерю скорости в два раза. API и нужно для того, чтобы решение точно соответствовало задаче.

ещё более хорошо заметно, что этот подход хорош только для проектов, которые ещё не доросли до требований, которые при их изначальном проектировании не планировались. тот же пример с evolution.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Есть ли будущее реляционных баз данных"  
Сообщение от geekkoo (ok) on 15-Фев-09, 13:41 
>>не говоря о том, что так называемая проверка на целостность обычно сопровождается индексами. или Вы какие-то другие приложения имели ввиду?

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

А с индексами ещё интересней. ИМХО, столь любимая поклонниками SQL реляционная алгебра ничего про индексы не говорит. В ней понятия упорядоченного множества нет вообще. О какой тогда индексации можно говорить? А именно индексация с точки зрения практики и представляет наибольший интерес (как раз интереснее ускорить доступ к данным, по разному их упорядочив). А  реляционной алгебре на эту бытовуху плевать. Т.е. как хотите, так и крутитесь.

И эта терминология "ключ-значение" вводит в заблуждение. Это не имеет отношение к типу структур, которые можно запихать в эти базы данных, а просто напоминает, что у нас не симметричное relation, а именно направленное "ключ->значение".

Вот пример. Стандартное отношение many-to-many - товар-магазин. Если его реализовывать в BDB , то в первую очередь нужно выяснить, какой именно запрос нам нужен - в каком магазине продается товар, или ассортимент товаров в магазине? Начнем с первого. Тогда у нас есть три таблицы (в формате ключ->значение).
1)Вторичный индекс "название товара -> индекс товара"
2)Первичный индекс "где купить?" "индекс товара -> индекс магазина"
3)Дополнительная таблица с расшифровкой индекса магазина "индекс магазина -> название магазина".
Т.е. понятие индекса тут ключевое и поиск осуществляется, как поиск по вторичному индексу ("название товара") индекса магазина и его последующая расшифровка. Понятно, чтобы изобразить relation нужны второй комплект таблиц с обратной направленностью (т.е. ровно удвоенное количество данных). Только по условиям задачи - нужно ли нам полное отношение?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "Есть ли будущее реляционных баз данных"  
Сообщение от User294 (ok) on 16-Фев-09, 01:41 
>Только по условиям задачи - нужно ли нам
>полное отношение?

А вот будет база хоть немного посложнее и ситуация начнет напоминать программирование на асме - вроде в результате круто и быстро, но начиная с некоторого объема кода башню програмеру срывает и получается просто трудноподдерживаемое лоскутное одеяло в котором черт ногу сломит.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 16-Фев-09, 02:00 
>>Только по условиям задачи - нужно ли нам полное отношение?
>
>А вот будет база хоть немного посложнее и ситуация начнет напоминать программирование на асме - вроде в результате круто и быстро, но начиная с некоторого объема кода башню програмеру срывает и получается просто трудноподдерживаемое лоскутное одеяло в котором черт ногу сломит.

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

Сразу видно, что разработками вы толком и не занимались.

И процитированную вами фразу вы скорее всего не поняли. А просто так, на удачу, в традиционной своей манере вставили комментарий.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

21. "Есть ли будущее реляционных баз данных"  
Сообщение от User294 (ok) on 16-Фев-09, 02:49 
>Значит по-вашему то, что "башню програмеру срывает", и когда "получается просто трудноподдерживаемое
>лоскутное одеяло", по-вашему это зависит именно от выбора языка, а не
>от способностей "програмера".

Это значит что вы не понимаете что есть некие очевидные соотношения, только и всего.При прочих равных некий (сферический) програмер (в вакууме :D) за равное время на сях обычно осиливает более крупную программу чем на асме.

>И по-вашему именно "асм" может "снести башню" сильнее,
>чем что-либо другое.

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

>И по вашему "лоскутные одеяла" появляются именно в
>результате использования непонятных для вас языков.

Непонятных - это каких?Если вы про асм - всосите уже, да?А то у меня хобби такое есть: программинг всяких небольших железок с экзотичной архитектурой.Как правило - RISC процессоры (ARM, AVR, 80C166, ... ) хотя бывали и другие.Кстати да, асм у таких обычно куда приятнее х86 ужастиков.И мне даже нравится.Но это не значит что я буду мег кода выписывать на асме.Да застрелите мну меговое фирмваре на асме писать - более изящного садо-мазо я затрудняюсь придумать :)))

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

Провоцируют.Но тем не менее, если прикидка показывает что некое абстрактное сферическое фирмваре в вакууме по фичности будет большое и толстое и никак не уместится в ~десяток кил - думаете, я буду использовать при его написании асм как основной язык?Черта с два - это я вам предоставлю так трахаться :D.А сам поюзаю нечто типа сей с небольшими вставками по месту асма где надо.Будет намного практичнее, портабельно и потом - намного меньше секса с развитием\поддержкой ;).Пусть и немного менее оптимально.

>Сразу видно, что разработками вы толком и не занимались.

А вы, видимо, супер-дупер-разработчик который спокойно перемалывает на асме мег кода не поперхнувшись, да?И как там крыша, не едет?Судя по вашим постам - таки едет... %)

>И процитированную вами фразу вы скорее всего не поняли. А просто так,
>на удачу, в традиционной своей манере вставили комментарий.

Как вам сказать?Самоличное разрюхивание структуры базы до набора пар (key, value) мне очень напомнило програминг на асме.По сути такое же сведение всего и вся к набору простейших операций.Оно может и не плохо.Если без фанатизма - иногда и в меру, там где это оправдано.Кстати чтобы вы не воняли лишний раз - могу сказать что юзал беркелеевскую БД от "сонного кота" например, она как раз оперирует парами (key, value) =)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

26. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 16-Фев-09, 10:11 
>Это значит что вы не понимаете что есть некие очевидные соотношения, только и всего.При прочих равных некий (сферический) програмер (в вакууме :D) за равное время на сях обычно осиливает более крупную программу чем на асме.

Между любыми сущностями или явлениями всегда можно найти какое-то соотношение. Вопрос, кто какие соотношения находит и между чем. Вы увидели именно такие соотношения именно между такими сущностями и явлениями.

В начале вы придрались к фразе об отношениях в реляционной модели. Почему-то вы провели при этом параллель именно с асмом. И упорно доказываете, что если использовать асм, то непременно должно получиться что-то большое и сложное. Вы почему-то при всем богатстве выбора стали рассуждать о написании на асме "меговых программ" и использовании асма в качестве "основного языка". Правда при этом вам абсолютно все равно - для чего, в какой области, для каких проектов.

Значит по вашим словам, если кто-то использует асм, то исключительно в качестве основного языка. И единственный способ при этом добиться хоть какой-то "фичности" по-вашему - это делать "меговый" код.

Также вы уверяете, что писание на асме под различные архитектуры - это ваше хобби.

У вас видимо единственный критерий оценки проектов - это "фичность", которая в свою очередь по-вашему в основном определяется размерами кода.

Судя по вашим высказываниям, если вам дать, скажем, php, то у вас получится либо "гиговое" лоскутное одеяло, либо у вас вообще не будет никакой "фичности".

>>И процитированную вами фразу вы скорее всего не поняли. А просто так, на удачу, в традиционной своей манере вставили комментарий.
>
>Как вам сказать?Самоличное разрюхивание структуры базы до набора пар (key, value) мне очень напомнило програминг на асме.

Что и требовалось доказать. Значит вы решили, что в процитированной вами фразе речь шла именно о наборах пар. Видимо только потому, что наборы пар тут часто упоминались. И, как я уже говорил, все непонятное у вас ассоциируется непременно с асмом, писание на котором, как вы утверждаете, является вашим хобби.

>По сути такое же сведение всего и вся к набору простейших операций.Оно может и не плохо.Если без фанатизма - иногда и в меру, там где это оправдано.Кстати чтобы вы не воняли лишний раз - могу сказать что юзал беркелеевскую БД от "сонного кота" например, она как раз оперирует парами (key, value) =)

БДБ "как раз оперирует парами"? - никто до вас этого не знал.

Ну уж конечно. О чем бы не зашла речь, так вы это непременно "юзали". Значит "юзание" БДБ у вас "свелось" именно "к набору простейших операций". Хотя при упоминании асма сами же заикнулись о трансляторах.

Как говорится, заставь "юзера" программировать, и у него все "сведется к набору простейших операций".

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

39. "Есть ли будущее реляционных баз данных"  
Сообщение от User294 (ok) on 17-Фев-09, 08:10 
>Вы увидели именно такие соотношения именно между такими сущностями и явлениями.

Да, я их увидел.И проверил на своей шкурке.So what?

>В начале вы придрались к фразе об отношениях в реляционной модели. Почему-то
>вы провели при этом параллель именно с асмом.

Потому что приведение всего и вся к виду (key, value) - возможно, но требует вручную сделать многое из того чего реляционные базы делают сами.Что чем-то напоминает асм - там тоже надо вручную делать многое из того что в ином случае сделал бы компилер.Вот и вся аналогия :)

>И упорно доказываете, что если использовать асм, то непременно должно
>получиться что-то большое и сложное.

Я доказываю что большое и сложное на асме делать попросту архигеморройно.Намного геморройнее чем то же самое, допустим, на сях.

>Вы почему-то при всем богатстве выбора стали рассуждать о написании
>на асме "меговых программ" и использовании асма в качестве "основного языка".

Мысль была примерно такой что реляционные БД имеют право на жизнь.Как и высокоуровневые языки программирования.

>Правда при этом вам абсолютно все равно - для чего, в
>какой области, для каких проектов.

Что, неужели вы так полагаете?Ху...й из вас телепат.Может, дворник из вас получше будет?

>Значит по вашим словам, если кто-то использует асм, то исключительно в качестве
>основного языка.

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

>И единственный способ при этом добиться хоть какой-то "фичности"
>по-вашему - это делать "меговый" код.

Чудес не бывает - если есть фичность, есть реализующий ее код.Чем больше фичности - тем больше кода.Даже на асме, прикиньте?! =)

>Также вы уверяете, что писание на асме под различные архитектуры - это
>ваше хобби.

Приколитесь?И такое тоже бывает.Правда нынче я стараюсь использовать си и асмовые вставки там где нужны.На чистом асме - геморройно уж очень.Благо, потом хочется добавить вон то, вон это ... и в итоге получается довольно много асмового добра которое в результате довольно геморройно поддерживать.Лично я начинаю чувствовать себя некомфортно когда размер кода на асме переваливает некую величину (несколько Кб, для меня - примерно 16).

>У вас видимо единственный критерий оценки проектов - это "фичность",

Не единственный но один из.А вот предвзятое отношение к оппоненту - не рулез и смахивает на троллинг :P

> которая в свою очередь по-вашему в основном определяется размерами кода.

По-моему эта логика доступна даже детсадовцу - функционала без кода не бывает.Больше функционала == больше кода.Ну а в результате долго живущие проекты (даже на асме!) отрастают большими.

>Судя по вашим высказываниям, если вам дать, скажем, php, то у вас
>получится либо "гиговое" лоскутное одеяло, либо у вас вообще не будет
>никакой "фичности".

Странный вывод.Вы прочли то что хотели прочесть относительно моей персоны а не то что я написал.Вот лол то.

>Что и требовалось доказать. Значит вы решили, что в процитированной вами фразе
>речь шла именно о наборах пар.

Насколько я понял - процитированный субъект описал именно реализацию которую можно сделать на основе баз (key, value).

>И, как я уже говорил,

Что бы вы ни говорили - это почему-то сводится к обсуждению моей персоны и левому трепу ;)

>БДБ "как раз оперирует парами"? - никто до вас этого не знал.

Ну, как минимум это знает еще оракл, скупивший оный, прям 1-й пункт в FAQ - http://www.oracle.com/technology/products/berkeley-db/faq/db...

Если вы не знаете - ну ой, faq можно было бы и почитать до выступлений по идее.

>Значит "юзание" БДБ у вас "свелось" именно "к набору простейших операций".

...для чего BDB и подходит наилучшим образом на мое имхо.Хорошая штука, если скорость работы - нужна а sql'ные навороты не требуются.База сонного кота вывешивает некое апи, достаточно простое для понимания.Можно по ключу значения тягать, есть курсоры и т.п. - для ряда применений вполне себе нормальная штука.Но вот интернет магазин на ней я бы делать не стал - при нужде что-то поменять больно много геморроя будет.

>Хотя при упоминании асма сами же заикнулись о трансляторах.

Мысль выглядит неоконченной.Что именно я говорил о трансляторах при упоминании асма (цитату не осилили?) и главное что вы хотели сказать этим?

>Как говорится, заставь "юзера" программировать, и у него все "сведется к набору
>простейших операций".

Я не виноват что процессоры так устроены.Честное слово.В конечном итоге они выполняют лишь набор простейших операций.Кстати почему-то из простейших кирпичей тем не менее умудряются построить целые дворцы.Странно, да? :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

41. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 17-Фев-09, 19:11 
Большую часть сообщения вы пытаетесь оправдаться якобы излишним вниманием к своей персоне и тем, что я по-вашему неправильно вас цитирую. Если вы уверены, что все дело в этом, тогда вам не о чем беспокоиться. Может быть читатели форума найдут другой смысл в ваших словах.

Итак, вот ваша самая первая придирка к фразе участника geekkoo.

>>Только по условиям задачи - нужно ли нам полное отношение?
>
>А вот будет база хоть немного посложнее и ситуация начнет напоминать программирование на асме - вроде в результате круто и быстро, но начиная с некоторого объема кода башню програмеру срывает и получается просто трудноподдерживаемое лоскутное одеяло в котором черт ногу сломит.

Теперь вы пытаетесь оправдываться.

>Потому что приведение всего и вся к виду (key, value) - возможно, но требует вручную сделать многое из того чего реляционные базы делают сами.Что чем-то напоминает асм - там тоже надо вручную делать многое из того что в ином случае сделал бы компилер.Вот и вся аналогия :)
>
>Я доказываю что большое и сложное на асме делать попросту архигеморройно.Намного геморройнее чем то же самое, допустим, на сях.
>
>Чудес не бывает - если есть фичность, есть реализующий ее код.Чем больше фичности - тем больше кода.Даже на асме, прикиньте?! =)

И так далее. В принципе вы просто повторяете то, что говорили ранее. Хотя все уже поняли, что вы считаете именно так. А именно, следующее.

Разговор об алгебраических отношениях (самая первая фраза) почему-то вызывает у вас ассоциацию именно с ассемблерами. Видимо потому, что вы одинаково плохо разбираетесь в обоих вопросах. То, что ассемблеры, по вашим словам, это ваше хобби, и то что вы утверждаете, что давно ими занимаетесь, вовсе не означает, что вы в этом хорошо разобрались. Что касается баз данных, то очевидно по вашим высказываниям, что вам так и не удалось увидеть, что пара (key, value) есть ничто иное, как алгебраическое отношение. А реляционная модель к вашему сведению построена на алгебре. Но естественно, что вам с вашими скудными познаниями в SQL, это невдомек.

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

Еще вы продолжаете настаивать, что главным критерием для вас в ПО является "фичность", и по-вашему чем больше "фичности", тем больше кода. Других вариантов, как я и предполагал, вы не знаете. Ну понял я, что вы именно так считаете, зачем второй раз повторять?

Потом вы продолжаете твердить, что якобы вас кто-то заставляет делать на ассемблере что-то большое и сложное. Однако на других языках делать что-то большое и сложное по-вашему нормально. Выходит вы считаете, что сложность измеряется сложностью и размером сгенерированного бинарного кода, а не исходного.

И продолжаете твердить, что дальше простейших операций с парами в БДБ вам продвинуться не удалось. Ну понятно уже, что у вас это было именно так, а вы все твердите.

>Мысль выглядит неоконченной.Что именно я говорил о трансляторах при упоминании асма (цитату не осилили?) и главное что вы хотели сказать этим?

Я так и думал, что самостоятельно вы эту мысль закончить не сможете, а ведь мысль была очень простая. Хорошо, как вы и просили, привожу вам ваши же слова, которые вы многократно твердите.

>Я доказываю что большое и сложное на асме делать попросту архигеморройно.Намного геморройнее чем то же самое, допустим, на сях.
>
>Мысль была примерно такой что реляционные БД имеют право на жизнь.Как и высокоуровневые языки программирования.
>
>Правда нынче я стараюсь использовать си и асмовые вставки там где нужны.На чистом асме - геморройно уж очень.

Ну так если есть высокоуровневые языки, то кто же вас заставляет писать "большое и сложное" на ассемблерах. Только ваше хобби. Точно также, кто заставляет вам ковыряться на уровне "простейших операций с парами", если есть высокоуровневые языки. Другой вопрос, что кроме SQL вы как видно ничего не знаете. Да и в SQL вы тоже разбираетесь плохо, если постоянно путаете его с реляционной моделью.

>Я не виноват что процессоры так устроены.Честное слово.В конечном итоге они выполняют лишь набор простейших операций.

Ну конечно, вы ни в чем не виноваты. Во все виноваты процессоры. Честное слово. Только почему-то вы видимо решили работать вместо процессоров, а что процессорам нужно поручать рутинную работу до вас так до сих пор видимо и не дошло, не смотря на ваше хобби.

>Кстати почему-то из простейших кирпичей тем не менее умудряются построить целые дворцы.Странно, да? :)

Кому-то суждено всю жизнь таскать кирпичи. Кто-то дворцы проектирует. А кто-то в них живет. Вы очевидно относитесь к первой категории. Поскольку в остальных вопросах, как это видно, вы мало что смыслите.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

43. "Есть ли будущее реляционных баз данных"  
Сообщение от User294 (??) on 17-Фев-09, 21:12 
>Большую часть сообщения вы пытаетесь оправдаться якобы излишним вниманием к своей
>персоне и тем, что я по-вашему неправильно вас цитирую.

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

>Может быть читатели форума найдут другой смысл в ваших словах.

Предоставим это читателям форума.

>Теперь вы пытаетесь оправдываться.

Опрвдаться?В чем?Перед кем?Вы бредите...

>Разговор об алгебраических отношениях (самая первая фраза) почему-то вызывает
>у вас ассоциацию именно с ассемблерами.

Мне, определенно нравится ваша логика - по ней всегда узнаешь о себе что-то новое.Но я все-таки не понимаю что надо скурить чтобы настолько "логично" рассуждать.

>Видимо потому, что вы одинаково плохо разбираетесь в
>обоих вопросах. То, что ассемблеры, по вашим словам, это ваше хобби,
>и то что вы утверждаете, что давно ими занимаетесь, вовсе не
>означает, что вы в этом хорошо разобрались.

Ну, мне для себя - нормально вроде (хотя разумеется не предел мечтаний).А мнение какого-то тролля с задранным самомнением о моей персоне и моих скиллах меня волнует в хренадцатую очередь, если честно.

>Что касается баз данных,
>то очевидно по вашим высказываниям, что вам так и не удалось
>увидеть, что пара (key, value) есть ничто иное, как алгебраическое отношение.

По-моему женская логика отдыхает на фоне вашей кульной и последовательной логики.Суть вашей логики: вбить себе в голову что-то насчет оппонента и с упорством достойным лучшего применения доказывать что оппонент - именно такой как вы себе его представили.Подгоняя решение под ответ и фигурно выпиливая из контекста цитаты.Очень напоминает законы Мерфи: теорию можно считать доказанной если для ее подтверждения необходимо отбросить не более 50% результатов измерений сделанных в ходе экспериментов :D.Вот вы именно такой деятельностью и занимаетесь - фигурно отбрасываете все что не подтверждает вашу теорию.

>А реляционная модель к вашему сведению построена на алгебре.

А еще дважды два - четыре.Наверное это круто, да?

>Но естественно,
>что вам с вашими скудными познаниями в SQL, это невдомек.

Конечно.Куда нам, дуракам, чай пить?Кстати а это не вас ли тут ткнули носом в этот факт недавно?:D Я так смотрю, вы узнали для себя нечто новое и теперь считаете своим долгом показать всем вокруг какие они тупые а вы умный, обладающий сакральным знанием, да?Выглядит прикольно, да :)

>должно непременно получиться что-то большое и сложное.

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

>Еще вы продолжаете настаивать, что главным критерием для вас в ПО является
>"фичность",

Давайте от противного?:) Меньше фичности - меньше кода.В предельном случае - полезного кода вообще нет и соответственно - оно никому кроме автора нафиг не надо потому что ничего полезного не делает.

>и по-вашему чем больше "фичности", тем больше кода.

Т.е. надо понимать что вы с этим не согласны?Расскажите нам, тупеньким, о Гуру, как сделать так чтобы новая фичность появлялась без дописывания для этого нового кода?Мне, черт побери, интересно, правда-правда :)

>Других вариантов, как я и предполагал, вы не знаете.

В то что новый функционал появляется путем черной магии без дописывания для этого кода - я не верю, увы и ах :P.

>Потом вы продолжаете твердить, что якобы вас кто-то заставляет делать на ассемблере
>что-то большое и сложное.

Нет, никто не заставляет (а где я говорил что заставляют?:P).Но зато отметил что часто в результате проект вырастает крупнее чем изначально задумывалось и потом поддержка и расширение функционала становится реальным таким геморроем.Особенно когда пишут на асме, пытаются все представить в виде (key, value) и т.п..Не видите разницы?Ну, может потом увидите.Теперь я кажется понимаю почему грамотных прожект манагеров уважают и почему это дано не всем.Вот вы бы на данной роли скорее всего быстро угробили бы любой даже самый дельный и перспективный проект, если бы его судьба зависела только от вас и вы были бы тем человеком кто принимает судьбоносные для проекта решения.Знаете в чем секрет?Не всегда самое компактное, быстрое и эффективное решение - самое лучшее.Еще существует время на разработку и сложность развития и поддержки проекта.Те кто забивает на столь простые истины обычно потом обнаруживают что они оказывается были ССЗБ.

>Выходит вы считаете, что сложность измеряется сложностью
>и размером сгенерированного бинарного кода, а не исходного.

А вам не кажется что размер бинарного кода коррелирует с размером исходного кода?Нет, писать исходный код который не порождает в итоге никакого машинного кода - можно конечно, но вот нафига бы?Единственный осмысленный пример - коментарии в коде разве что.И то хороши в меру.А то если програмер пишет одни коменты - толку то с такой программы? :)

>И продолжаете твердить, что дальше простейших операций с парами в БДБ вам
>продвинуться не удалось.

А я пытался?Для меня не характерно забивать гвозди микроскопом.Даже если микроскоп - прибор крутой и симпатичный мне.Беркелеевская база хорошая штука.Но универсальной заменой SQL ни разу не является.Разумеется в теории и с такой БД можно реализовать все что угодно, точно так же как на асме можно в теории написать любую программу.Просто геморроя будет здорово больше а поддержка проекта может превратится в реальный геморрой.Сиквель хорош тем что даже достаточно сложные конструкции на нем выглядят компактно и понятно.Клинические случаи разумеется в пример брать не будем (вы это любите но это ваши половые трудности).

>что процессорам нужно поручать рутинную работу до вас так до сих
>пор видимо и не дошло, не смотря на ваше хобби.

Напротив, это до меня дошло и уже давно.А вот ваша "логика" меня удивляет.Интересно что надо курить чтобы такой отличаться столь непоследовательной и странной логикой?

>Кому-то суждено всю жизнь таскать кирпичи. Кто-то дворцы проектирует. А кто-то в
>них живет. Вы очевидно относитесь к первой категории.

Это вы по себе чтоли оценили?А то вы у меня вызываете стойкое ощущение ретивого но глуповатого кодера который годен только на то чтобы супер-ровно и быстро класть кирпичи (гордясь этим) и получая тычки от начальства за медленную скорость.Аналитическое мышление у вас не развито как класс во всяком случае.Наглядный такой антипод компетентного прожект манагера ведущего свой проект к процветанию.

>Поскольку в остальных вопросах, как это видно, вы мало что смыслите.

Думаете меня очень волнует ваша экспертная оценка?Нет, есть люди чья оценка моей персоны таким образом уронила бы мою самооценку.Но вы в число таких людей не входите.Хотя-бы потому что все ваши "достижения" виденные мной сводятся к растопырке пальцев, громким заявам и рассуждениям на тему "все - пи...сы, а я - Д`Артаньян".Есть только одна проблема: так любой идиот может и я не вижу пока чем вы отличаетесь от миллионов оных.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

44. "Есть ли будущее реляционных баз данных"  
Сообщение от geekkoo (ok) on 17-Фев-09, 22:04 
BerkeleyDB хороший движок, на котором можно накрутить, что угодно. Тот же SQL (причем сразу с транзакциями) что было реализовано в MySQL до 5.1, или же даже Третий манифест -
http://duro.sourceforge.net/. Понятно, что proof-of-concept, но код там весит меньше, чем SQLite, причем реализуется химически чистое реляционное исчисление.

А с Postgres-ом, вопрос сложный. ПОнятно, что его автор Стоунбрэйкер все пытался усовершенстововать реляционную модель, создав странного гибрида - реляционную базу данных с наследованием. Так что скорее всего там изначально было много отступлений от чистой реляционной модели. Но потом этот код неоднократно перекраивали  (когда, например, туда SQL прицепили), так что сложно сказать, что там осталось от первоначальных концепций...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

45. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 17-Фев-09, 22:16 
>А с Postgres-ом, вопрос сложный. ПОнятно, что его автор Стоунбрэйкер все пытался усовершенстововать реляционную модель, создав странного гибрида - реляционную базу данных с наследованием. Так что скорее всего там изначально было много отступлений от чистой реляционной модели. Но потом этот код неоднократно перекраивали  (когда, например, туда SQL прицепили), так что сложно сказать, что там осталось от первоначальных концепций...

Наследование хорошо согласуется с реляционной моделью. Как впрочем и объектная модель вообще. Все это можно описать алгебраически и без противоречий. Проблема Постгрес именно в том, каким образом там реализована объектная модель на концептуальном уровне. И как вы правильно заметили, отступление от реляционной модели там наблюдается одновременно.

Трудно судить, что было там сначала - неправильная реализация объектной модели или реляционной. В любом случае одно с другим тесно взаимосвязано.


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

46. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 18-Фев-09, 00:29 
>или же даже Третий манифест - http://duro.sourceforge.net/.

Кстати о Третьем манифесте. Вот вы сами, geekkoo, и практически нашли ответ на вопрос, который хотели от меня получить. По крайней мере максимально близко к нему подобрались. Так что я в вас не сомневался.

>А с Postgres-ом, вопрос сложный.

Не такой уж он и сложный, если разобраться. Дэйт в своей критике творений Стоунбрэйкера конкретно указывает, где у последнего наблюдаются алгебраические противоречия.

А вот за ссылку на Duro - отдельное спасибо. Относительный свежачок с января 2008. Я его честно признаться упустил. Наконец-то Дэйт сделал реализацию своей теории, и ни на чем ином, как на БДБ. То что нужно! Можно свой парсер прикрутить и творить все что вздумается.

>>Хотя при упоминании асма сами же заикнулись о трансляторах.

User294:
>Мысль выглядит неоконченной.Что именно я говорил о трансляторах при упоминании асма (цитату не осилили?) и главное что вы хотели сказать этим?

Вот вам, User294, кстати, дополнительная информация, чтобы закончить мысль. А то вам так и придется с вашим хобби возиться с ассемблерами и парами, или с SQL. И злиться, что у вас все время код получается большим и сложным.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

47. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 18-Фев-09, 18:00 
Практически все ваше сообщение состоит из оправданий по поводу ваших предыдущих оправданий. А также небольшого числа банальных повторов, где вы продолжаете что-то там твердить про ассемблеры, когда речь идет о базах данных. На это я уже ответил выше.

Внимания может заслужить только следующей поучительный момент.

>>Еще вы продолжаете настаивать, что главным критерием для вас в ПО является "фичность", и по-вашему чем больше "фичности", тем больше кода. Других вариантов, как я и предполагал, вы не знаете. Ну понял я, что вы именно так считаете, зачем второй раз повторять?
>
>Давайте от противного?:) Меньше фичности - меньше кода.В предельном случае - полезного кода вообще нет и соответственно - оно никому кроме автора нафиг не надо потому что ничего полезного не делает.

Итак, вы попробовали рассуждать от противного. Вы рассуждаете, что чем меньше фичности, тем меньше по-вашему будет кода. Ну и уж если фичнось убрать вообще, то полезного кода тоже не будет. Замечательно. Только что при этом вы пытаетесь доказать? Что количество кода зависит от "фичности", или что "фичность" зависит от количества кода. Ну да, они зависят друг от друга. Никто и не спорит.

Однако эти рассуждения вы по прежнему делаете из собственного критерия, что полезность измеряется размером кода. То есть по-прежнему, как я уже неоднократно обращал внимание, "фичность" и количество кода являются для вас главными критериями в оченке качества проектов и больше вам особо не о чем говорить.

>>Выходит вы считаете, что сложность измеряется сложностью и размером сгенерированного бинарного кода, а не исходного.
>
>А вам не кажется что размер бинарного кода коррелирует с размером исходного кода?Нет, писать исходный код который не порождает в итоге никакого машинного кода - можно конечно, но вот нафига бы?Единственный осмысленный пример - коментарии в коде разве что.И то хороши в меру.А то если програмер пишет одни коменты - толку то с такой программы? :)

Итак, вы подтверждаете, что вы оцениваете сложность по сгенерированному коду, а не по исходному.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Есть ли будущее реляционных баз данных"  
Сообщение от User294 (ok) on 15-Фев-09, 21:52 
>стороне приложения. И RDBMS за собой тянут ещё кучу подобного оверхеда,
>включая парсер SQL.

Ага, какой-нить sqlite весит ~300 кил (как статичный код).С парсером sql и движком базы.Что-то я его тяжелым монстром с диким оверхедом обозвать ну никак не могу.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 16-Фев-09, 02:21 
Вы как всегда продолжаете демонстрировать всю глубину ваших познаний в области программирования.

>>стороне приложения. И RDBMS за собой тянут ещё кучу подобного оверхеда, включая парсер SQL.
>
>Ага, какой-нить sqlite весит ~300 кил (как статичный код).С парсером sql и движком базы.Что-то я его тяжелым монстром с диким оверхедом обозвать ну никак не могу.

В том-то и дело, что он и является сам по себе эти самым оверхедом. А вы значит считаете его движком. Ну да, все конечно относительно. Какую-нибудь библиотеку для чтения-записи dbf-файла тоже можно считать движком. И чего там больше по-вашему - движка базы или парсера SQL с "оверхедом"? Учтите при этом полную блокировку всего файла БД при начале транзакции. И прочее количество функционала из области "движков БД".

И значит вы считаете, что для библиотеки 300k (статичного кода) - это очень мало по-вашему. Кстати, а что вы имели в виду, под статичным кодом?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "Есть ли будущее реляционных баз данных"  
Сообщение от User294 (ok) on 16-Фев-09, 03:06 
>В том-то и дело, что он и является сам по себе эти
>самым оверхедом. А вы значит считаете его движком.

Гм.Просто у других в таком объеме кода чисто движок (страничная логика, транзакционные логи, b-деревья или что там у них заместо, ...) далеко не всегда умещаются в эти 300 кил.

>И чего там больше по-вашему - движка базы или парсера SQL
>с "оверхедом"?

В таком контексте затрудняюсь сравнить, не заморачивался.Зато знаю что допустим беркелеевская база от сонного кота, оперирующая (key, value) нифига не меньше весит.Хоть там и нет парсера SQL... =)

>Учтите при этом полную блокировку всего файла БД при
>начале транзакции. И прочее количество функционала из области "движков БД".

И что?Блокировки и в базах (key, value) бывают.Вон у того же сонного кота в базе блокировки есть.Равно как и транзакции.В результате не больно то оно мало весит.Хоть и без парсера SQL.По-моему оно даже тяжелее sqlite'а получается в итоге.Хотя казалось бы всего-то база оперирующая парами (key, value) :)

>И значит вы считаете, что для библиотеки 300k (статичного кода) - это
>очень мало по-вашему.

"А случаи бывают разными" (с) анекдот :).Если у меня однокристалка где памяти в сумме меньше - 300Кб за "очень мало" не считается.На обычном десктопе\сервере 300 Кб - достаточно незначительный размер кода.

>Кстати, а что вы имели в виду, под статичным кодом?

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

24. "Есть ли будущее реляционных баз данных"  
Сообщение от geekkoo (ok) on 16-Фев-09, 09:03 
>[оверквотинг удален]
>
>>Учтите при этом полную блокировку всего файла БД при
>>начале транзакции. И прочее количество функционала из области "движков БД".
>
>И что?Блокировки и в базах (key, value) бывают.Вон у того же сонного
>кота в базе блокировки есть.Равно как и транзакции.В результате не больно
>то оно мало весит.Хоть и без парсера SQL.По-моему оно даже тяжелее
>sqlite'а получается в итоге.Хотя казалось бы всего-то база оперирующая парами (key,
>value) :)
>

Блокировки есть. По-страничные при записи. А конфликт между чтением-записью вообще можно  обойти за счет мультиверсионности.
>[оверквотинг удален]
>десктопе\сервере 300 Кб - достаточно незначительный размер кода.
>
>>Кстати, а что вы имели в виду, под статичным кодом?
>
>Вероятно вопрос в том что я имел в виду под размером статичного
>кода?Это размер на который распухает бинарь при статической линковке с некоей
>либой при юзании этой самой либы и ее функционала.Это (примерно) соответствует
>размеру кода этой либы.Достаточно распостраненная методика оценки увесистости чего-либо.Я думал это
>очевидно - вроде довольно популярный у програмеров "писькомер", странно что мимо
>вас прошло.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

29. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 16-Фев-09, 10:57 
>>В том-то и дело, что он и является сам по себе эти самым оверхедом. А вы значит считаете его движком.
>
>Гм.Просто у других в таком объеме кода чисто движок (страничная логика, транзакционные логи, b-деревья или что там у них заместо, ...) далеко не всегда умещаются в эти 300 кил.

Ну вот вы сами и подтвердили мои слова, что он в отличии от других является скорее "оверхедом" с парсером, чем движком БД.

>>И чего там больше по-вашему - движка базы или парсера SQL с "оверхедом"?
>
>В таком контексте затрудняюсь сравнить, не заморачивался.Зато знаю что допустим беркелеевская база от сонного кота, оперирующая (key, value) нифига не меньше весит.Хоть там и нет парсера SQL... =)

Правильно, зато там есть продвинутый движок БД, а также мощная независимая библиотека транзакций, которая долгое время использовалась в вашей любимой MySQL до появления InnoDB. Вы продолжаете сами себя опровергать.

>>Учтите при этом полную блокировку всего файла БД при начале транзакции. И прочее количество функционала из области "движков БД". Вы продолжаете сами себя опровергать.
>
>И что?Блокировки и в базах (key, value) бывают.Вон у того же сонного кота в базе блокировки есть.Равно как и транзакции.В результате не больно то оно мало весит.Хоть и без парсера SQL.По-моему оно даже тяжелее sqlite'а получается в итоге.Хотя казалось бы всего-то база оперирующая парами (key, value) :)

По-вашему получается, что блокировки в базах - это некое нежелательное явление. Не говоря уже о транзакциях. А вот парсер SQL - это по-вашему самое главное в базах данных. Ну да, если кроме как через SQL к данным не подобраться. Вы продолжаете демонстрировать всю глубину своих познаний.

>>И значит вы считаете, что для библиотеки 300k (статичного кода) - это очень мало по-вашему.
>
>"А случаи бывают разными" (с) анекдот :).Если у меня однокристалка где памяти в сумме меньше - 300Кб за "очень мало" не считается.На обычном десктопе\сервере 300 Кб - достаточно незначительный размер кода.

Ну и так уже понятно, что вы считаете 300Кб - очень мало для библиотеки. Да, если весь ваш опыт - это "обычный десктоп\сервер" в дистрибутивах, которые пытаются угнаться за Вистой в вопросах поддержки "обычных юзеров\ламеров".

>>Кстати, а что вы имели в виду, под статичным кодом?
>
>Вероятно вопрос в том что я имел в виду под размером статичного кода?

А вот и нет. Я спросил что именно вы понимаете под "статичным" кодом? Если учесть еще, что как вы заявили выше, программирование на ассемблерах под различные платформы - это ваше хобби.

>Это размер на который распухает бинарь при статической линковке с некоей либой при юзании этой самой либы и ее функционала.Это (примерно) соответствует размеру кода этой либы.Достаточно распостраненная методика оценки увесистости чего-либо.Я думал это очевидно - вроде довольно популярный у програмеров "писькомер", странно что мимо вас прошло.

Как я и предполагал, задавая этот вопрос. Кто-то код пишет и линкует, а кто-то пытается это со стороны понять и придумывает всякие "популярные писькомеры". Главное популярность. Так вот и получаются эксперты по размерам.

Значит по вашему размер "статичного" кода распухает не только после линковки, но и в процессе "юзания", причем отдельно для самой "либы" и отдельно для ее функционала.

Значит если вас попросят взвесить, скажем, колесо от автомобиля, вы сначала открутите у автомобиля колеса, взвесите автомобиль, потом прикрутите колеса, снова взвесите. Потом прикинете на сколько стал тяжелее автомобиль при "статичной" прикрутке колес. Это (примерно) соответствует весу колес. Главное не забыть потом поделить на четыре. А почему примерно? Ну конечно это теория относительности. Ведь пока вы "статично" прикручивали-откручивали, часть воздуха ведь могла выйти из камер на колесах. А воздух, как известно тоже вес имеет. А если посчитать при этом еще изменение выталкивающей силы окружающей атмосферы, то действительно получится "достаточно распостраненная методика оценки увесистости чего-либо".

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

40. "Есть ли будущее реляционных баз данных"  
Сообщение от User294 (ok) on 17-Фев-09, 09:10 
>Ну вот вы сами и подтвердили мои слова, что он в отличии
>от других является скорее "оверхедом" с парсером, чем движком БД.

Как всегда - благородный дон прочел то что хотел прочитать между строк он сам, а не то что там реально написано :)))

>Правильно, зато там есть продвинутый движок БД, а также мощная независимая библиотека
>транзакций, которая долгое время использовалась в вашей любимой MySQL до появления
>InnoDB. Вы продолжаете сами себя опровергать.

Что - опровергать?Размер кода у беркелеевской базы получается довольно нехилый в результате.Без всякого сиквела вообще.А sqlite в 300 кил кода таскает и движок БД (при том вполне достаточный для многих задач и как-то не отличающийся особой тормознутостью при правильном юзеже) и ... sql-парсер.В свете этого заявы про жуткий оверхед от самого по себе парсера sql - чистоплюйство высосанное из пальца.В какой-никакой оверхед по скорости - поверю.Но - юзеж си тоже дает некоторый оверхед.Давайте только на асме программить?Не хотите? :)

>По-вашему получается, что блокировки в базах - это некое нежелательное явление.

Почему нежелательное то?Желательное. Если с хорошей гранулярностью и т.п. (и да, упомянутый мной sqlite именно по части блокировок - не силен, но в конечном итоге это зачастую не есть проблема).

> Не говоря уже о транзакциях.

А вы осилите привести цитату где я говорил что транзакции ... нежелательны?!Хаха, узнаю о себе много нового :D

>А вот парсер SQL - это по-вашему самое главное в базах данных.

Просто без него иногда слишком геморройно получается.Вы же не станете выписывать прогу с огроменным функционалом на асме?Ну вот и тут аналогично.

>Ну да, если кроме как через SQL к данным не подобраться.

Вай-вай-вай, что вы такое говорите?Я вообще-то хотел сказать что в случае навороченных запросов - добираться до данных как-то иначе, например несколькими дюжинами запросов (key, value) может быть попросту не в меру геморройно.Оно ессно можно, и если аккуратно делать запросы - даже возможно будет быстрее чем то что изобразит sql-парсер+движок БД.Ну вот вы вот так и подбирайтесь к данным всегда и везде, флаг вам в руки.А я как-нибудь буду это делать только в простейших случаях - где мне очевидно что нужна скорость а навороты sql нафиг не впились.А то я не живу вечно и самолично распихивать навороченные конструкции на кучку запросов (key, value) меня может и заломать.Ага?

>Вы продолжаете демонстрировать всю глубину своих познаний.

А вы продолжаете обсуждать личности оппонентов, старательно избегая демонстрации своих знаний.Boring crap...

>Ну и так уже понятно, что вы считаете 300Кб - очень мало
>для библиотеки.

Как я уже сказал - оценка мало или много зависит от того где эта библиотека будет использоваться.И не надо пытаться передергивать и перевирать.Это инфантильно.

>Да, если весь ваш опыт - это "обычный десктоп\сервер"

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

>в дистрибутивах, которые пытаются угнаться за Вистой в вопросах поддержки "обычных
>юзеров\ламеров".

Да, мой компьютер достаточно мощен для того чтобы мне за ним было удобно а 300 килобайтная библиотека на нем была просто незаметной.И даже на карманном устройстве типа n800 300 Кб библиотека не является криминалом.Ну а в каких-то специальных случаях типа однокристалок и точка зрения на размер - специальная.Тут все просто.

>А вот и нет. Я спросил что именно вы понимаете под "статичным"
>кодом?

Собственно имелся в виду статически прилинкованый к программе код библиотеки.

>Если учесть еще, что как вы заявили выше, программирование на
>ассемблерах под различные платформы - это ваше хобби.

Да, это мое хобби.И мне оно нравится.И я не собираюсь впихивать в однокристалку с 8 кило флеша на борту и килом оперативки sqlite на 300 кил - у меня в отличие от некоторых все дома и в таком специальном случае я вполне готов сделать поправку на размер всей системы в целом.So what?Что вы сказать то хотели?Факты о себе я и без вас знаю.Получше вас.

>Как я и предполагал, задавая этот вопрос. Кто-то код пишет и линкует,
>а кто-то пытается это со стороны понять

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

>и придумывает всякие "популярные писькомеры".

Как ни странно - множество оных было придумано програмерами.Факты как-то не на вашей стороне, увы... :)

>Главное популярность. Так вот и получаются эксперты по размерам.

Если честно - я бы вас даже экспертом по размерам не назвал бы.Пока вы даже таких знаний не продемонстрировали - вы пока показали свой экспертный уровень только в растопыривании пальцев разве что. It's boring...

>Значит по вашему размер "статичного" кода распухает не только после линковки, но
>и в процессе "юзания", причем отдельно для самой "либы" и отдельно
>для ее функционала.

Скажите честно: что вы курите, что вы способны на основе моих фраз построить столь нелепую заяву и столь далеко идущие измышлизмы? Are you on drugs? Грибочками не злоупотребляете?  oO

>А почему примерно?

Да потому что точный размер кода для библ никто обычно не замеряет с точностью до бита.Да и вообще с этим на практике есть кой-какие проблемы.Например, если библу построить как DLL - формально можно говорить о размере кода и прочая.Вот только там еще всякие выравнивания секций будут, "служебные" данные типа заголовков и т.п.. Более того - выравнивание секций вполне может (и будет) распостраняться на итоговый бинарь и при просто статичной линковке либы в оный.Посему рост размера бинаря вовсе не обязан точно соответствовать добавленному коду с точностью до байта.Вот оттуда мое "примерно" и проистекает.

>"достаточно распостраненная методика оценки увесистости чего-либо".

Нет, мне натурально интересно: где вы такую забористую траву берете? =)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

42. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 17-Фев-09, 20:42 
>>Учтите при этом полную блокировку всего файла БД при начале транзакции.
>
>И что?Блокировки и в базах (key, value) бывают.Вон у того же сонного кота в базе блокировки есть.Равно как и транзакции.В результате не больно то оно мало весит.Хоть и без парсера SQL.По-моему оно даже тяжелее sqlite'а получается в итоге.Хотя казалось бы всего-то база оперирующая парами (key, value) :)
>
>>По-вашему получается, что блокировки в базах - это некое нежелательное явление.
>
>Почему нежелательное то?Желательное. Если с хорошей гранулярностью и т.п. (и да, упомянутый мной sqlite именно по части блокировок - не силен, но в конечном итоге это зачастую не есть проблема).

По смыслу первой цитаты видно, что вы посчитали блокировку чем-то нежелательным. А все потому, что вы толком еще в этот момент не знали, что это такое. Потом вы спохватились и что-то почитали в Инете о "гранулярности". Но как видно далее, вы все еще не разобрались в связи между блокировками и транзакциями.

>> Не говоря уже о транзакциях.
>
>А вы осилите привести цитату где я говорил что транзакции ... нежелательны?!Хаха, узнаю о себе много нового :D

В той же цитате. "Блокировки и в базах (key, value) бывают. <...> Равно как и транзакции." Теперь оправдывайтесь, не оправдывайтесь, а уровень своих познаний вы уже показали. Это ваша традиционная манера, которая хорошо видна во всех ваших сообщениях на форуме - вы говорите о вещах, в которых плохо разбираетесь, и прикрываетесь всякими словечками, значение которых тоже толком не поняли.

Читаем далее.

>Что - опровергать?Размер кода у беркелеевской базы получается довольно нехилый в результате.Без всякого сиквела вообще.А sqlite в 300 кил кода таскает и движок БД (при том вполне достаточный для многих задач и как-то не отличающийся особой тормознутостью при правильном юзеже) и ... sql-парсер.В свете этого заявы про жуткий оверхед от самого по себе парсера sql - чистоплюйство высосанное из пальца.В какой-никакой оверхед по скорости - поверю.Но - юзеж си тоже дает некоторый оверхед.Давайте только на асме программить?Не хотите? :)

С учетом сказанного выше получается, что в sqlite толком транзакции не реализованы, потому и скорость большая. Так что пользуясь вашим же любимым критерием "фичности", sqlite - и есть в основном "оверхед" с парсером SQL. Вы уже в третий раз это сами же подтвердили. Ну и то, что вы считаете, что для такого "оверхеда" 300 Кб - это мало.

Потом вы снова много сравниваете пары с ассемблером. И говоря о высоуровневых языках, продолжаете подтверждать, что кроме посредственного знакомства с SQL вы о базах данных мало что знаете. Я на это более подробно уже ответил здесь https://www.opennet.ru/openforum/vsluhforumID3/49435.html#41.

>Да, мой компьютер достаточно мощен для того чтобы мне за ним было удобно а 300 килобайтная библиотека на нем была просто незаметной.И даже на карманном устройстве типа n800 300 Кб библиотека не является криминалом.Ну а в каких-то специальных случаях типа однокристалок и точка зрения на размер - специальная.Тут все просто.

Мы уже выяснили, что вы считаете, что 300Кб для библиотеки - это по вашему очень мало, можно было не повторяться.

>Ага, какой-нить sqlite весит ~300 кил (как статичный код).С парсером sql и движком базы.
>
>Это размер на который распухает бинарь при статической линковке с некоей либой при юзании этой самой либы и ее функционала.Это (примерно) соответствует размеру кода этой либы.Достаточно распостраненная методика оценки увесистости чего-либо.Я думал это очевидно - вроде довольно популярный у програмеров "писькомер", странно что мимо вас прошло.
>
>Как ни странно - множество оных было придумано програмерами.Факты как-то не на вашей стороне, увы... :)
>
>Собственно имелся в виду статически прилинкованый к программе код библиотеки.
>
>Да потому что точный размер кода для библ никто обычно не замеряет с точностью до бита.Да и вообще с этим на практике есть кой-какие проблемы.Например, если библу построить как DLL - формально можно говорить о размере кода и прочая.Вот только там еще всякие выравнивания секций будут, "служебные" данные типа заголовков и т.п.. Более того - выравнивание секций вполне может (и будет) распостраняться на итоговый бинарь и при просто статичной линковке либы в оный.Посему рост размера бинаря вовсе не обязан точно соответствовать добавленному коду с точностью до байта.Вот оттуда мое "примерно" и проистекает.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 15-Фев-09, 22:29 
>Странную альтернативу двигает автор... Не смотря на то, что в некоторых областях key/value databases действительно применимы, реляционную модель В БОЛЬШИНСТВЕ областей заменить сложно.

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

>Уже настораживает. А чем тогда мешает создать в postgreSQL одну таблицу и назвать ее доменом. Уже отсутствуют реляционные связи.

Очередной пример непонимания разницы между реляционной моделью и стандартом SQL. То что в SQL понятие "таблица" существует - это факт? А насколько уместно вообще применять термин "таблица" в реляционной модели? И насколько вообще стандарты SQL и их реализации соответствуют реляционной модели? И, наконец, что мешает реализовать реляционную модель с помощью механизма key-value?

P.S. Я ничего не имею против самой реляционной модели данных. Однако, насколько хорошо она реализована в существующих системах?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Есть ли будущее реляционных баз данных"  
Сообщение от Stanislaus email(ok) on 16-Фев-09, 00:55 
>P.S. Я ничего не имею против самой реляционной модели данных. Однако, насколько
>хорошо она реализована в существующих системах?

Может реляционная модель в своем чистом виде немного не практична и не очень интересна?
Поэтому те, кто пытается адаптировать ее для практических целей, решают допускать "ошибки", ради практичности. В принципе, разработчики postgreSQL этого не скрывают и нам об этом сообщают. PostgreSQL is a powerful, open source object-relational database system.

> То что в SQL понятие "таблица" существует - это факт? А насколько уместно вообще применять термин "таблица" в реляционной модели?

"table"="relvar", "column"="attribute", "row"="tuple", как то привык, что они взаимозаменяемы. Мы же говорим о базах данных, а не моделях =).

>И, наконец, что мешает реализовать реляционную модель с помощью механизма key-value?

Ну, помешает терминология наверное. =)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 16-Фев-09, 01:38 
>Может реляционная модель в своем чистом виде немного не практична и не очень интересна?

Практична она или нет, зависит от конкретной реализации. То что существует мало практичных ее реализаций - наверное можно согласиться. Интересна она или нет - это индивидуальный вопрос. Большинству вообще математика не интересна. А вот тем, кому интересна математика - скорее всего реляционная модель очень интересна.

>Поэтому те, кто пытается адаптировать ее для практических целей, решают допускать "ошибки", ради практичности. В принципе, разработчики postgreSQL этого не скрывают и нам об этом сообщают. PostgreSQL is a powerful, open source object-relational database system.

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

>> То что в SQL понятие "таблица" существует - это факт?

Я случайно поставил знак вопроса. Я хотел это сказать в утвердительной форме.

>>А насколько уместно вообще применять термин "таблица" в реляционной модели?
>"table"="relvar", "column"="attribute", "row"="tuple", как то привык, что они взаимозаменяемы.

Уже ближе. Тем не менее, значит для вас они взаимозаменяемы во всех случаях.

>Мы же говорим о базах данных, а не моделях =).

Может вы о моделях и не говорите, а я говорю именно о моделях в данном случае. Хотя из этого не совсем понятно, то ли вы считаете, что модели к базам данных не относятся, то ли вы считаете, что в статье вообще речь о моделях не шла.

>>И, наконец, что мешает реализовать реляционную модель с помощью механизма key-value?
>
>Ну, помешает терминология наверное. =)

То есть вы считаете, что терминология здесь может как-то помешать.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

25. "Есть ли будущее реляционных баз данных"  
Сообщение от geekkoo (ok) on 16-Фев-09, 09:08 
>> То что в SQL понятие "таблица" существует - это факт?
>
>Я случайно поставил знак вопроса. Я хотел это сказать в утвердительной форме.
>

Читая предыдущий параграф, я уж было подумал, что у вас точка на клавиатуре отломилась, и вы её повсюду вопросом заменили ;)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

27. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 16-Фев-09, 10:16 
>Читая предыдущий параграф, я уж было подумал, что у вас точка на клавиатуре отломилась, и вы её повсюду вопросом заменили ;)

И запятые у меня тоже последнее доживают.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Есть ли будущее реляционных баз данных"  
Сообщение от User294 (ok) on 14-Фев-09, 16:32 
Не, key\value это круто и (иногда) весьма даже рулит.Но, блин, только иногда.Утверждать что всегда надо юзать только такие БД - что-то типа утверждения что программы необходимо всегда писать только на асме :)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Есть ли будущее реляционных баз данных"  
Сообщение от s390 email on 15-Фев-09, 15:41 
Ага. А ещё плоские файлы есть.;-)
С фиксированными полями - скорость просто бещенная. И никакого специализированного API учить не надо.
Если еще запихать туда списочную структуру в виде JSON или XML - уж гибкость то...

От прочтения статьи ощущение что автор сильно ушибленный, и с вопросами обработки данных имел дело на уровне написания телефонного справочника секретарши для фирмы "Рога и Копыта".
PS. Если вспомнить что ещё иерархические с сетевыми СУБД вполне так себе неплохо живут...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Есть ли будущее реляционных баз данных"  
Сообщение от Я (??) on 15-Фев-09, 16:27 
в питоне pickle с этим справляется и с json тоже.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Есть ли будущее реляционных баз данных"  
Сообщение от geekkoo (ok) on 15-Фев-09, 18:26 
Сериализация тут при чём?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Есть ли будущее реляционных баз данных"  
Сообщение от geekkoo (ok) on 15-Фев-09, 18:19 
>Ага. А ещё плоские файлы есть.;-)
>С фиксированными полями - скорость просто бещенная. И никакого специализированного API учить
>не надо.

Зачем передергивать? Ага, давайте потом прицепим к файлу вторичную индексацию, приделаем транзакции, page-level locks, курсоры, распределенные операции. Делов то ...
>Если еще запихать туда списочную структуру в виде JSON или XML -
>уж гибкость то...
>
>От прочтения статьи ощущение что автор сильно ушибленный, и с вопросами обработки
>данных имел дело на уровне написания телефонного справочника секретарши для фирмы
>"Рога и Копыта".
>PS. Если вспомнить что ещё иерархические с сетевыми СУБД вполне так себе
>неплохо живут...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Есть ли будущее реляционных баз данных"  
Сообщение от geekkoo (ok) on 15-Фев-09, 18:41 
>[оверквотинг удален]
>Зачем передергивать? Ага, давайте потом прицепим к файлу вторичную индексацию, приделаем транзакции,
>page-level locks, курсоры, распределенные операции. Делов то ...
>>Если еще запихать туда списочную структуру в виде JSON или XML -
>>уж гибкость то...
>>
>>От прочтения статьи ощущение что автор сильно ушибленный, и с вопросами обработки
>>данных имел дело на уровне написания телефонного справочника секретарши для фирмы
>>"Рога и Копыта".
>>PS. Если вспомнить что ещё иерархические с сетевыми СУБД вполне так себе
>>неплохо живут...

Никто и не говорит, что нашли серебрянную пулю.
Я вот в какой-то книжке прочитал, что есть три user-case:
1) Статичные (более-менее) данные и динамические запросы. Условно говоря, у нас есть набор данных и мы не вполне знаем, что именно из этих данных мы хотим извлечь. Это SQL.
2) Статичные данные и статичные запросы. LDAP - самое оно для этого.
3) Динамичные данные и статичные запросы. Т.е. данные меняются очень быстро (генерируются автоматически), а запросы происходят редко и имеют фиксированную структуру. Это как раз ниша этих key-value баз данных.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 15-Фев-09, 22:46 
>Не, key\value это круто и (иногда) весьма даже рулит.Но, блин, только иногда.Утверждать что всегда надо юзать только такие БД - что-то типа утверждения что программы необходимо всегда писать только на асме :)

Утверждать, что всегда следует использовать использовать "только такие БД", это конечно сугубо личное мнение авторов статьи.

Также как и утверждение, что что-то "рулит" только иногда - это тоже всего лишь чье-то личное мнение.

Все зависит от вкусов, знаний и умений. В чьих-то руках и "асм" будет всегда "рулить", а у кого-то даже на SQL будет что-то получаться только "иногда".

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "Есть ли будущее реляционных баз данных"  
Сообщение от User294 (ok) on 16-Фев-09, 03:15 
>Все зависит от вкусов, знаний и умений. В чьих-то руках и "асм"
>будет всегда "рулить", а у кого-то даже на SQL будет что-то
>получаться только "иногда".

Видел несколько проектов на асме где объем кода более нескольких десятков кил.Хоть застрелите не понимаю что там рулит - выглядит такое довольно уныло.Поскольку в таком виде написаны обычно изделия проприетарной эпохи - пруфлинка не будет.Хотя в качестве примера могу сказать например про сорц старого авардовского биоса - типовой представитель такого кода ;).Глядя на оный невольно понимаешь почему более новые биосы типа coreboot'а пишут на сях.Такой объем функционала на асме сооружать получается попросту некомфортно.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "Есть ли будущее реляционных баз данных"  
Сообщение от mnimd (ok) on 16-Фев-09, 10:21 
>Видел несколько проектов на асме где объем кода более нескольких десятков кил.Хоть застрелите не понимаю что там рулит - выглядит такое довольно уныло.Поскольку в таком виде написаны обычно изделия проприетарной эпохи - пруфлинка не будет.Хотя в качестве примера могу сказать например про сорц старого авардовского биоса - типовой представитель такого кода ;).Глядя на оный невольно понимаешь почему более новые биосы типа coreboot'а пишут на сях.Такой объем функционала на асме сооружать получается попросту некомфортно.

Значит заключение о том, что пары (key, value) по-вашему "рулят" только иногда, это заключение вы сделали на сновании того, что вам довелось увидеть какие-то проекты "на асме где объем кода более нескольких десятков кил".

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

38. "Есть ли будущее реляционных баз данных"  
Сообщение от Аноним (??) on 16-Фев-09, 13:00 
Не нашел слова "пруфлинк" в словаре русского языка.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

48. "Есть ли будущее реляционных баз данных"  
Сообщение от Аноним (??) on 20-Фев-09, 08:37 
Почитал всю эту вату, которую тут раскатали. Особенно заинтересовало заявление mnimd об концептуальной ошибке в постгресе. После прочитал все комменты. Кроме этого заявления больше ничего не нашёл. Где про это почитать-то можно? И желательно не между строк, а для чайников, черным по белому..
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру