Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 .. 25   вперед  Ctrl
 Re: Конец SQL?  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
okidoki
Эээ, пошел какой-то поток.... Давайте разберемся хотя бы с ДЖОИН. Дальше будет проще. Итак.
Анархасис
пропущено...
А не Дедал ли это ? Он тоже напевал, что во всей субд должна быть одна табличка
Может в этом и ограниченность СКЛщиков, что всё они видят через таблицу? Почему обязательно нужно говорить "выберите мне таблицу отделов связанных с таблицей таких-то сотрудников...", вместо простого "выберите мне отделы связанные с такими-то сотрудниками". Неужели это всё последствия еще тех СУБД, когда данные нужно было хранить в отдельных файлах и называть эти файла таблицами? Ведь данные в ввиде
ОТДЕЛ(СОТРУДНИК,...)...)

выглядят на много проще чем в СКЛ-моделях
ОТДЕЛ(ОТДЕЛ_ИД,...)
СОТРУДНИК(СОТРУДНИК_ИД, ОТДЕЛ_ИД, ...)

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

ЗЫ Тем более если 1й способ ("ключ-значение") может работать быстрее, чем 2й способ ("таблицы") :)

Что значит пошел поток?
На 13824475 и должен был пойти поток, начавшийся, как обычно, с "не правильных приложений" и "правильных оптимизаторов". Факты звучат обидно, а опровергнуть их нельзя. Конечно, будет поток.
Теперь о Вашем примере. Вы заблуждаетесь. Не симметричный доступ - известная проблема РМД, а Вы его еще больше усугубляете. См., например, 13545785.
В "реляционной технологии" даже теоретически не могут соблюдаться основные принципы БД. См., например, 13254920.
Детализацию проблемы с "триадой" см., например, в 13755686.
То есть, все поднимаемые здесь вопросы многократно и всесторонне рассмотрены в прошлых темах:)
25 янв 13, 19:54    [13830338]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
Yo.!
AlexKB
"Определенный унитаз" из миллиона в MUMPS находится одной командой - он же определен!

ничерта не знаю про MUPS, но есть воросы:
1. если мне понадобилось унитазы размазать по нескольким серверам и несколько другой структуры ? команда останется та же ?
2. если мне нужно достать несколько унитазов, кто мне обеспечит консистентность ? т.е. что бы я не получил набор унитазов которые на момент окончания чтения уже удалили и те что при старте чтения еще не были забиты в базу.

Так изучите. Чтобы не задавать много лет одни и те же вопросы, бравируя своим незнанием. Это вопросы о СУБД (зайдите в раздел Cache, и задайте там свои вопросы).
А MUMPS - не СУБД.
25 янв 13, 19:57    [13830358]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okidoki
Может в этом и ограниченность СКЛщиков, что всё они видят через таблицу?

Угу. Сейчас все бросим, и буим через
okidoki
"ключ-значение"

смотреть.

okidoki
Почему ....
Неужели ...

Вы даже Вику про Мангу не почитали?

Вот там, например:
"MongoDB, по мнению разработчиков, должна заполнить разрыв между простыми хранилищами данных типа «ключ-значение» (быстрыми и легко масштабируемыми) и большими РСУБД (со структурными схемами и мощными запросами)."

Возможно, из этого текста бы сами догадались "Почему".
25 янв 13, 23:26    [13831153]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
okidoki
Member

Откуда:
Сообщений: 36
locky
okidoki,

угу, "сотрудник"
Это там он - "сотрудник", а "вот там" - начальник, "там" - совместитель, там - еще кто нить

и в каждом "там" хранится полный набор инфы об этом человеке - или как?
Ну давайте разберемся на примере. На JSON я бы представил так, если в БД одна коллекция.
{
Отдел:{
  Имя:"ОПО",
  Сотрудник:{Имя:"Иванов",Должность:"начальник"},
  Сотрудник:{Имя:"Раков",Должность:"программист"}
},
Отдел:{
  Имя:"ОТО",
  Сотрудник:{Имя:"Раков",Должность:"начальник"},
  Сотрудник:{Имя:"Раков",Должность:"техник", Совместитель:true}
}
}

Можно получить полную информацию о всех Раковых без их идентификации. Но никто не мешает их идентифицировать. Особенно, если используются ещё другие коллекции.
{
Отдел:{
  Имя:"ОПО",
  Сотрудник:{Ид:001,Имя:"Иванов",Должность:"начальник"},
  Сотрудник:{Ид:002,Имя:"Раков",Должность:"программист"}
},
Отдел:{
  Имя:"ОТО",
  Сотрудник:{Ид:003,Имя:"Раков",Должность:"начальник"},
  Сотрудник:{Ид:002,Имя:"Раков",Должность:"техник", Совместитель:true}
}
}

Попробуйте теперь на SQL со всеми нормализациями и тд. Вам чтобы уйти от избыточности, обязательно придется думать, кого по каким таблицам разложить и как их назвать и идентифицировать. А при составлении отчетов снова будете складывать (группировать).
26 янв 13, 14:53    [13832924]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
okidoki
Member

Откуда:
Сообщений: 36
Бредятина
okidoki
Ведь данные в ввиде
ОТДЕЛ((СОТРУДНИК,...)...)

выглядят на много проще чем в СКЛ-моделях
ОТДЕЛ(ОТДЕЛ_ИД,...)
СОТРУДНИК(СОТРУДНИК_ИД, ОТДЕЛ_ИД, ...)


Теперь о Вашем примере. Вы заблуждаетесь. Не симметричный доступ - известная проблема РМД, а Вы его еще больше усугубляете. См., например, 13545785.
Во 2м случае я сделал то, что сделал бы каждый реляционнщик, те нормализовал таблицы. Разумеется, во 2м случае, чтобы сохранить целостность, ещё придется определять ОТДЕЛ_ИД как Внешний ключ (FK) для сотрудников.
26 янв 13, 14:54    [13832927]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
okidoki
Member

Откуда:
Сообщений: 36
vadiminfo
Вы даже Вику про Мангу не почитали?
Вот там, например:
"MongoDB, по мнению разработчиков, должна заполнить разрыв между простыми хранилищами данных типа «ключ-значение» (быстрыми и легко масштабируемыми) и большими РСУБД (со структурными схемами и мощными запросами)."

Возможно, из этого текста бы сами догадались "Почему".
А вы читайте вику на английском. Там больше мнений разработчиков (а не ссылок на них). И там больше примеров и меньше философии. Когда-то ПК тоже предполагали, как дополнение к МаинФрейму
26 янв 13, 14:55    [13832929]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
okidoki
Можно получить полную информацию о всех Раковых без их идентификации. Но никто не мешает их идентифицировать. Особенно, если используются ещё другие коллекции.
А теперь еще можно вспомнить, что у всех этих Раковых есть паспорта, телефоны, история зарплаты с 1913 года, взыскания, текущие задачи, дружеские отношения...
Фигня - вместо фамилии запихнем в каждый отдел структуру и будем туда все это складывать. Заодно в отдел можно добавить сведения о курируемых проектах (в каждом проекте конечно же кроме дат есть, например, список участвующих сторудников) ну и т.д.
26 янв 13, 15:52    [13833124]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
okidoki
Бредятина
пропущено...

Теперь о Вашем примере. Вы заблуждаетесь. Не симметричный доступ - известная проблема РМД, а Вы его еще больше усугубляете. См., например, 13545785.
Во 2м случае я сделал то, что сделал бы каждый реляционнщик, те нормализовал таблицы. Разумеется, во 2м случае, чтобы сохранить целостность, ещё придется определять ОТДЕЛ_ИД как Внешний ключ (FK) для сотрудников.

:) Для чего Вы это написали??? Остается только надеяться, что Вы поняли, что оба варианта плохие, но первый хуже второго:)
26 янв 13, 16:25    [13833218]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okidoki
А вы читайте вику на английском. Там больше мнений разработчиков (а не ссылок на них). )

А мне то зачем? Мне Манго сто лет не нужна (если нужно будет, то и у Оракла есть NoSQL).

Вы задавали вопросы начинающих на техническом форуме, не поискав на них ответы в инете. Я лишь сказал, что на такие вопросы найти ответы даже в Вики про Мангу, которую взялись пиарить. (Мне кажется что слишком топорно, по Дедаловски, впрочем.)

okidoki
Когда-то ПК тоже предполагали, как дополнение к МаинФрейму

Любите выдумывать аналогии?
Ну так тада такая.
Вы пришли пиарить квадрациклы, и спрашиваете: почему вы все тут ездите на автомобилях. Квадрацикл типа выглядит проще.
А Вам говорят, что ответ на такой вопрос можно узнать даже у квадрациклистов. А Вы начинаете отправлять всх спрашивать про это у англоязычных квадрациклистов.
26 янв 13, 18:22    [13833557]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Анархасис
Member [заблокирован]

Откуда: Страна Полимеров
Сообщений: 1963
okidoki
locky
okidoki,

угу, "сотрудник"
Это там он - "сотрудник", а "вот там" - начальник, "там" - совместитель, там - еще кто нить

и в каждом "там" хранится полный набор инфы об этом человеке - или как?
Ну давайте разберемся на примере. На JSON я бы представил так, если в БД одна коллекция.
{
Отдел:{
  Имя:"ОПО",
  Сотрудник:{Имя:"Иванов",Должность:"начальник"},
  Сотрудник:{Имя:"Раков",Должность:"программист"}
},
Отдел:{
  Имя:"ОТО",
  Сотрудник:{Имя:"Раков",Должность:"начальник"},
  Сотрудник:{Имя:"Раков",Должность:"техник", Совместитель:true}
}
}

Можно получить полную информацию о всех Раковых без их идентификации. Но никто не мешает их идентифицировать. Особенно, если используются ещё другие коллекции.
{
Отдел:{
  Имя:"ОПО",
  Сотрудник:{Ид:001,Имя:"Иванов",Должность:"начальник"},
  Сотрудник:{Ид:002,Имя:"Раков",Должность:"программист"}
},
Отдел:{
  Имя:"ОТО",
  Сотрудник:{Ид:003,Имя:"Раков",Должность:"начальник"},
  Сотрудник:{Ид:002,Имя:"Раков",Должность:"техник", Совместитель:true}
}
}

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


От раковых уже в глазах рябит. И это только начало ...
26 янв 13, 22:28    [13834464]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Анархасис
Member [заблокирован]

Откуда: Страна Полимеров
Сообщений: 1963
Если чо, в таблицах будет так

ID Должность
1 Начальник
2 Программист
3 Техник


ДолжностьID ЧеловекID
1 1
2 1
3 1
1 2


ЧеловекID Имя Паспорт
1 Раков ММ 1111
2 Иванов ММ 2222
26 янв 13, 22:32    [13834470]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Анархасис
Member [заблокирован]

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

Во-вторых, есть вьювы, есть процедуры, есть функции, с помощью которых вы можете абстрагироваться от нормализированого хранения данных. И в будуйщем не нужно будет 100500 раз все джойнить, достаточно использовать вьюв с готовым отображением, витрина данных.
26 янв 13, 22:39    [13834481]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Анархасис

ЧеловекID Имя Паспорт
1 Раков ММ 1111
2 Иванов ММ 2222

Кроме паспорта, пусть для начала добавит еще дату рождения, страховой, рост, чтобы посмотреть как будет разруливать избыточность у этого Ракова.
(паспорт то мог меняться).
26 янв 13, 23:18    [13834564]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 52942
Думаю что SQL/РМД позволяет создавать практические любые отчеты с одинаковыми
затратами на их (отчётов) разработку. Тоесть мы строим модель исходя из
правил НФ (3 уровня) и предположения что заказчик захочет сформировать
совершенно любой отчет.

Для NoSQL - мы заведомо должны знать какой именно отчёт хочет получать
заказчик и скомпоновать чтобы данные были извлечены быстро и эффективно.

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

Для вышеуказанного примера (мы ничего не знаем об отчетности) я вправе
декларировать структуру и данные следующим образом. Вот так.

{
Должность:{
  Имя:"Начальник",
  Сотрудник:{Имя:"Иванов"},
},
Должность:{
  Имя:"Программист",
  Сотрудник:{Имя:"Раков"},
  Сотрудник:{Имя:"Бредятина"},
  Сотрудник:{Имя:"Базист"},
  Сотрудник:{Имя:"mayton"},
}
}


И моя структура имеет столько же прав на существование сколько и прочие структуры.
Я не нарушил никаких правил. А теперь вопросы. Что с оптимизатором? Как
моя недальновидность при проектировании может просадить перформанс?
Где потенциальный bottleneck? Как я должен был проектировать хранилище
чтобы минимизировать риски связанные с "физическим распылением" кортежей
по всему стореджу?
27 янв 13, 00:16    [13834679]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
mayton
Думаю что SQL/РМД позволяет создавать практические любые отчеты с одинаковыми
затратами на их (отчётов) разработку. Тоесть мы строим модель исходя из
правил НФ (3 уровня) и предположения что заказчик захочет сформировать
совершенно любой отчет.

Фундаментальное заблуждение. При использовании SQL/РМД заказчик никаких отчетов получить не сможет. Для этого придется использовать архитектуру "модель верхнего уровня+маппинг+РМД".
mayton
Для NoSQL - мы заведомо должны знать какой именно отчёт хочет получать
заказчик и скомпоновать чтобы данные были извлечены быстро и эффективно.

Фундаментальное заблуждение. Интерактивный интерфейс и возможность получать непредусмотренные отчеты на основании семантически развитой логической МД - это неотъемлемая часть любой СУБД.
Поэтому, "реляционные системы" не являются СУБД. Как это не парадоксально (планировался ведь "естественный язык запросов"), но РМД стала непреодолимой стеной между пользователем и данными. И необходимо перманентное программирование.
mayton
Но всегда ли мы владеем информацией о том какие отчеты могут понадобиться? Это вопрос.

Практически, никогда.
mayton
Для вышеуказанного примера (мы ничего не знаем об отчетности) я вправе
декларировать структуру и данные следующим образом. Вот так....
...
И моя структура имеет столько же прав на существование сколько и прочие структуры.
Я не нарушил никаких правил. А теперь вопросы....

После указанных заблуждений какую ценность, по Вашему, может иметь этот текст?
Вы в начале пути изучение теории и технологий БД. И пройдя его, Вы, конечно, на эти вопросы ответите адекватно:)
27 янв 13, 02:17    [13834842]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4809
Бредятина
Интерактивный интерфейс и возможность получать непредусмотренные отчеты на основании семантически развитой логической МД - это неотъемлемая часть любой СУБД.
немного жаль, что таких СУБД не существует до сих пор, но мы не отчаиваемся, мы - ждём
27 янв 13, 02:59    [13834875]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
egorych
Бредятина
Интерактивный интерфейс и возможность получать непредусмотренные отчеты на основании семантически развитой логической МД - это неотъемлемая часть любой СУБД.
немного жаль, что таких СУБД не существует до сих пор, но мы не отчаиваемся, мы - ждём


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

egorych:
пожалуй, вы ответили на мой изначальный вопрос

А про себя решили, что не существует:)
Так или иначе, но в своем последнем сообщении mayton, по существу, ставит вопрос о разработке СУБД.
И нужно хорошо понимать принципы БД, чтобы браться за такую задачу.
27 янв 13, 10:57    [13835007]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 52942
Бредятина
Фундаментальное заблуждение. При использовании SQL/РМД заказчик никаких отчетов получить не сможет. Для этого придется использовать архитектуру "модель верхнего уровня+маппинг+РМД".

У нас - разное понимание проблемы. Какой смысл ты вкладываешь в термин "отчёт"?
27 янв 13, 12:03    [13835100]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 52942
Бредятина
Поэтому, "реляционные системы" не являются СУБД.

Перед поэтому должен был следовать какой-то сложный тезис с доказательством.
Или ссылка на фундаментальные труды. Я нигде не читал подобного (из чего
следовало-бы что РС не являются СУБД.
27 янв 13, 12:06    [13835106]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
egorych
немного жаль, что таких СУБД не существует до сих пор, но мы не отчаиваемся, мы - ждём

Особенно, если бы эти СУБД умели читать мысли заказчиков, анализировать предметную область, проектировать БД, разрабатывать все программы на лету по желанию Клиента, а не тока какие-то там отчеты генерить. Вообще, и самих заказчиков бы заменили - сами принимали все решения.
Правда, тада МУМПС стал бы еще меньше нужен чем даже теперь, но это детали.
27 янв 13, 13:12    [13835193]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Yo.!
Guest
Бредятина
Интерактивный интерфейс и возможность получать непредусмотренные отчеты на основании семантически развитой логической МД

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

Бредятина
Поэтому, "реляционные системы" не являются СУБД. Как это не парадоксально (планировался ведь "естественный язык запросов"), но РМД стала непреодолимой стеной между пользователем и данными.

толи дела каша, внедрившая SQL ради преодоления стены с пользователями
27 янв 13, 13:46    [13835251]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
mayton
Бредятина
Фундаментальное заблуждение. При использовании SQL/РМД заказчик никаких отчетов получить не сможет. Для этого придется использовать архитектуру "модель верхнего уровня+маппинг+РМД".

У нас - разное понимание проблемы. Какой смысл ты вкладываешь в термин "отчёт"?

Тогда сначала четко сформулируйте проблему, которая Вас беспокоит в рамках данной темы. И мы обязательно добьемся одинакового понимания.
27 янв 13, 14:46    [13835376]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
mayton
Бредятина
Поэтому, "реляционные системы" не являются СУБД.

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

Вы игнорируете даже такие простые и понятные тезисы, основанные на фундаментальных трудах (я подробно цитировал Дейта, когда пояснял этот тезис):
"Интерактивный интерфейс и возможность получать непредусмотренные отчеты на основании семантически развитой логической МД - это неотъемлемая часть любой СУБД."
И требуете непременно сложных тезисов:) И непременно фундаментальные труды:) В этом и заключается проблема образования в сфере БД (ориентация на коммерческий шаблон), которая также многократно здесь обсуждалась.
27 янв 13, 14:52    [13835388]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
vadiminfo
egorych
немного жаль, что таких СУБД не существует до сих пор, но мы не отчаиваемся, мы - ждём

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

MUMPS в технологии БД - это то же самое, что и колесо в технике. Она будет нужна всегда. Потому что предназначена для:
1) разработки СУБД;
2) решения информационно-логических задач на основе концепции БД без использования СУБД.
То есть, покрывает все потребности разработчиков приложений БД.
27 янв 13, 14:56    [13835396]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
Yo.!
... еще тачскрин для МД обязателен.
форумные хомячки бывают такими смешными !

Бравирование незнанием теории БД и неспособность обсуждать вопросы по существу - это взаимосвязанные явления:)
Yo.!
толи дела каша, внедрившая SQL ради преодоления стены с пользователями

А это закономерное следствие:) SQL только усиливает стену, что очевидно. Не могу поверить, что такие очевидные вещи можно не понимать. Значит умышленное ёрничанье:) Вероятно, под влиянием проблем то ли оральки, то ли трескульки:)
27 янв 13, 15:01    [13835417]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 .. 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить