О современном программировании

[AndreyS]

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

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

[kvinta]

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

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

Вот вопрос AndreyS. Как себя ведёт эта "программа SERVER SQL" по отношению к другим программ.
Простая задача. Надо загрузить последовательный файл (например справочник телефонов). На сколько просто это Вам удастся сделать?
И обратно надо из БД выгрузить данные в последовательный файл. Что то в руководстве об этом не было сказано ничего (в 90-х годах). Может сейчас эта проблема решена? Или SQL так и остался глухой и немой для общения?

[kvinta]

Всех с православных праздником Сретения.
Воронеж. Грустная история.
Пошел вчера платить в Сбербанк за квартиру. Наличные платежи не принимают. Почему?
Обновление программы. Что это у нас: β-тестирование в рабочее время и на всех пользователях Сбербанка? Где администратор сервера?  Объясняют: администратора нет, сервера нет, все данные в Екатерин_бурге-Свердловске (оптимизация)!
Как этот красивый, молодой, серьезный человек, которого видел раньше - где? Уволен!
И так по всем филиалам Сбербанка. «Приходите завтра с утра, связь будет».
Утром захожу: «Вы пришли поздно, связь опять пропала, ждите!»
Через 3 часа оплатил за 10 минут все счета и пошел думать о современном программировании и связи; народ продолжал мучиться у терминалов оплаты, вводя счета, показания и прочее.

[BJIaquMup]

Воронеж.

Как? Уже?
 +@>

[kichrot]

...
Вот вопрос AndreyS. Как себя ведёт эта "программа SERVER SQL" по отношению к другим программ.
Простая задача. Надо загрузить последовательный файл (например справочник телефонов). На сколько просто это Вам удастся сделать?
И обратно надо из БД выгрузить данные в последовательный файл. Что то в руководстве об этом не было сказано ничего (в 90-х годах). Может сейчас эта проблема решена? Или SQL так и остался глухой и немой для общения?

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

[kvinta]

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

А реляционные БД  не универсальный механизм? Не общая теория обработки информации.
Теперь «удобнее» отдать программирование на СИ++ индусам (благо они дешевле в 5 раз, пусть они занимаются этой мурой), а самим заниматься написанием спецификаций и называть это - Современным программированием. Дожили.

[kvinta]

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

[kichrot]

А реляционные БД  не универсальный механизм? ...

Нет, это достаточно узкое направление в программировании. 

[kichrot]

... Работать нужно хорошим инструментом, будьте требовательны к инструменту с которым работаете (отладка, трасировка). Главная цель - это польза пользователя-заказчика.
Удобную программу пользователь любит и благодарит всякого разработчика и пользуется ей долгое время.

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

[kichrot]

...
Теперь «удобнее» отдать программирование на СИ++ индусам (благо они дешевле в 5 раз, пусть они занимаются этой мурой), а самим заниматься написанием спецификаций и называть это - Современным программированием. Дожили.

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

[BJIaquMup]

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

"Если ничего не помогает, прочитайте же вы наконец инструкцию!"
Из Законов Мэрфи

 +@>

[AndreyS]

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

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

Вот вопрос AndreyS. Как себя ведёт эта "программа SERVER SQL" по отношению к другим программ.
Простая задача. Надо загрузить последовательный файл (например справочник телефонов). На сколько просто это Вам удастся сделать?

Если файл с разделителями между полями либо поля фиксированной длины, и если загружать в таблицу со структурой полей соответствующей файлу - сделаю минут за 5-10.

И обратно надо из БД выгрузить данные в последовательный файл. Что то в руководстве об этом не было сказано ничего (в 90-х годах). Может сейчас эта проблема решена? Или SQL так и остался глухой и немой для общения?

Выгрузка данных, в простом варианте, делается мин за 5-10. Для этого в SQL Server имеется bcp и SSIS.
В 90-х годах, когда SQL Server уже существовал, также был bcp и был DTS.
Так что все есть, нужно лишь знать документацию.

[kvinta]

Прекрасно. Остался пустяк. Сделать распределённую БД по узлам иерархии пользователей и решить вопрос информационного обмена результатов расчёта между ними.
Тогда получим распределённую однородную иерархическую БД и распределённую параллельную систему расчётов. Симфония. Мечта любого пользователя (программиста).
Сейчас идёт обратный процесс. Централизации информации в одном месте.

[Petrovich_Tot]

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

слова не мальчика, но мужа. 

[kichrot]

Прекрасно. Остался пустяк. Сделать распределённую БД по узлам иерархии пользователей и решить вопрос информационного обмена результатов расчёта между ними.
Тогда получим распределённую однородную иерархическую БД и распределённую параллельную систему расчётов. Симфония. Мечта любого пользователя (программиста).
Сейчас идёт обратный процесс. Централизации информации в одном месте.

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

[kvinta]

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

Вот пример диаметрально противоположного заблуждения.
1. Надёжность резко возрастает (пример напомню - интернет сеть первоначально предназначалась для работы в условиях атомной войны). Она распределённая и надёжная. Выход одного узла в сети, БД не уничтожает. Наоборот сосредоточенность управления порождает его уязвимость и ненадёжность.
2. По (локальной) сети нужно гонять требуемые (итоговые) данные, а не всё подряд, да там трафик и не критичен.
3. Конфигурация распределённой БД может и не содержать избыточных данных. Зависит всё от архитектора БД.
Надёжность БД решается грамотным периодическим, автоматическим архивированием данных (дед, отец, сын). В этом случае потеря данных практически исключена.
Централизация БД как раз и порождает аварийные ситуации для всех пользователей и порождает проблемы с ремонтопригодностью узлов и локальных сбоев.

[kichrot]

Вот пример диаметрально противоположного заблуждения.
1. Надёжность резко возрастает (пример напомню - интернет сеть первоначально предназначалась для работы в условиях атомной войны). Она распределённая и надёжная. Выход одного узла в сети, БД не уничтожает. Наоборот сосредоточенность управления порождает его уязвимость и ненадёжность.
2. По (локальной) сети нужно гонять требуемые (итоговые) данные, а не всё подряд, да там трафик и не критичен.
3. Конфигурация распределённой БД может и не содержать избыточных данных. Зависит всё от архитектора БД.
Надёжность БД решается грамотным периодическим, автоматическим архивированием данных (дед, отец, сын). В этом случае потеря данных практически исключена.
Централизация БД как раз и порождает аварийные ситуации для всех пользователей и порождает проблемы с ремонтопригодностью узлов и локальных сбоев.

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

[kvinta]

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

Туфта. 
Правильно оценили своё высказывание.
Надёжность и безопасность выше любых экономических показателей.
Это проверенно на реальных военных приложениях и БД, они НАДЁЖНЫ и даже не используют "вражеских" микросхем, не то что экономических концепций.
 

[kichrot]

Туфта. 
Правильно оценили своё высказывание.
Надёжность и безопасность выше любых экономических показателей.
Это проверенно на реальных военных приложениях и БД, они НАДЁЖНЫ и даже не используют "вражеских" микросхем, не то что экономических концепций.

Комментарии излишни.