Переиздание книг Столярова по программированию

после таких историй если буду набирать на работу программистов, буду всем задавать вопрос про этот foxpro и прочие подобные сортирные технологии. тем кто ответит хоть на один такой вопрос сразу отсеивать дабы не наворотили такого вот говна.

ещё более характерен история генезиса журнал Доктора Доба

ваще там прям наглядно как из «окололабороторных» фрико-нёрдов+ентерпренёрров выросло современное (уже заслонённое следующими наслоениями) мега-корпоративное ююю

Никакие, это не философский, а сугубо структурно-системный вопрос.

Смена концепции и её идеологическое обоснование - не одно целое.

И рефрена никакого не было, бессмысленность потраченного времени, как правило очевидна.

прогресс история идеи

Фуко(тот ещё …) - и структурировании&классификации_по_клеточкам охватившее просветителей 18 вечка и неожирондированные последствия унификации мировосприятия.

бессмысленность(sic!) - относительно мыслимого пользу несущего поглощения времени

потраченного(sic!) - потраваЪрастрата потеря и прочая руска магуча языка

как правило (аппеляция к повторимости) очевидно (аппеляция к норме)

Можете меня на порог не пускать. Я видел работу dBASE под CP/M на рубеже тысячелетий. Без эмуляторов и прочего читерства.

А я так и вообще программировал dBase в её инкарнации Rebus под DOS в качестве курсовика для брата.

после таких историй если буду набирать на работу программистов, буду всем задавать вопрос про этот foxpro и прочие подобные сортирные технологии.

Вся твоя суть. Технологию ты не знаешь, но это не помешало тебе заклеймить её по паре ответов с ЛОРа.

Просто FoxPro (как и всё семейство dBase-подобных) — это локальные СУБД. Многопользовательские режимы к ним прикручивались в виде костылей. Т.е. в данном случае имеем использование технологии не совсем по назначению. И как тебе объяснил собеседник — её давно пора заменить, но легаси не пускает.

Симпатичный талисман у продукта http://www.dbase.com/wp-content/uploads/character_reveal_sign_17785.png

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

При чём здесь проприетарщина? Мы про технологию или про модель распространения? Или ты собираешься отказывать людям в приёме на работу только потому, что на предыдущей работе работодатель заставлял их писать под проприетарную СУБД? Если так, то хорошо, что ты людей на работу не принимаешь, и всё это только твои фантазии.

И что значит «нормальных»? Речь о том, что есть СУБД локальные, а есть клиент-серверные, у каждой своя область применения. Use-case локальной СУБД — какая-нибудь учётная программа в пределах одного рабочего места. Из свободных СУБД к этому классу относится SQLite, например.

А FoxPro (как и Paradox) свой рынок завоевала ещё в то время, когда готовых свободных реляционных СУБД пожалуй, что и не было. Они начали как-то развиваться уже во второй половине 90-х. Поэтому на проприетарные продукты массово сели, а слезать довольно проблематично, почему — предыдущий собеседник тебе объяснил.

Если бы я принимал на работу по крайней мере не получилась бы описанная предыдущим оратором выгребная яма из доисторического проприетарного софта. Проблематичность отказа от неё для меня пока не ясна. Данные можно же вытащить оттуда и поместить в sqlite. Так в чём проблема то? Это всё что там описано так дико звучит и отдаёт отвратительной прогнившей старинной проприетарщиной с костылями. Уж не знаю как там было в прошлом веке но в настоящее время, как уже писал другой оратор, 30 тысяч можно просто в памяти держать в JSON или XML.

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

Проблематичность отказа от неё для меня пока не ясна.

Ещё раз: БД работает не сама по себе, а сопряжена с различными аппаратными устройствами и обеспечивает торговлю на точке. Точке, которая работает 7 дней в неделю и НЕ МОЖЕТ простаивать.

Т.е. замена – это остановка в работе на неопределённый срок и куча расходов.

Выгрузить БД в читабельный формат могу и я сам, как и загрузить обратно, но вот кто запрограммирует новую СУБД под наши нужды? Т.е. создаст кнопочки, которые будут, например, выдавать список проданного за период и формировать из него расходную накладную/выгружаемый файл? Создание транспортной накладной, создание накладной заказа? Формирование уникальных штрих-кодов и внутренних артикулов? Загрузку приходной накладной и её проверку по факту? И лёгкий доступ ко всем этим накладным.

А ведь есть ещё поиск по разным критериям. Это не так-то просто. То, как это было в 1С – жуть. Там даже не смогли сделать поиск по регулярным выражениям! А различные способы поиска вызывались из разных мест меню.

30 тысяч можно просто в памяти держать в JSON или XML.

А потом отрубится напряжение и не синхронизированные данные с разных рабочих месть будут утрачены, ибо если ПК ещё снабжены UPS, то сетевой оборудование – нет. Стоимость самого примитивного UPS – 2,5 тыс.

кто запрограммирует новую СУБД под наши нужды? Т.е. создаст кнопочки, которые будут, например, выдавать список проданного за период и формировать из него расходную накладную/выгружаемый файл? Создание транспортной накладной, создание накладной заказа? Формирование уникальных штрих-кодов и внутренних артикулов? Загрузку приходной накладной и её проверку по факту? И лёгкий доступ ко всем этим накладным.

Не надо путать СУБД с ее клиентом.

Вы что вообще не знакомы с понятием software maintenance? Т.е. вот у вас как работает какая то античная проприетарщина из прошлого века 25 лет со времён когда не было доступно ни postgresql (у которой Initial release 8 July 1996; 24 years ago), ни sqlite (Initial release 17 August 2000; 20 years ago) так и будет сколько ещё работать? 25 лет!!! за это время любой open source проект тысячи новых версий выпустил. Не можете сами наймите хоть индуса за копейки, уверен намного лучше получится.

Не надо путать СУБД с ее клиентом.

СУБД – система управления базой данных. Где путаница?

вот у вас как работает какая то античная проприетарщина из прошлого века

Нет, сама АСТ-торговля активно «развивается» в том смысле, что фирма-поставщик её точит по нужды клиентов, проверяет совместимость с новыми ККМ, новыми версиями Винды и т.д.

Мне неизвестна предыстория вопроса, которая скорее всего так же про деньги, меньшие, чем за 1С. Я лишь привёл пример того, что неоптимизированное ПО, созданное высокоуровневыми инструментами, может создавать вполне реальные проблемы, которые невозможно решить задёшево.

Прикол ещё в том, что расширяя возможности своей проги или исправляя какие-то проблемы, эти прогеры портят что-нибудь другое. Видимо, из-за того, что невозможно залезть в «потроха» достаточно глубоко. Или из-за нежелания заморачиваться за те крохи, что фирма платила за исправления. Быстренько чего-то наваяли методами объектно-ориентированное событийного программирования в визуальном режиме и усё.

такова ниша.

дешевле вас озадачить чем …

и это печально.

там вообще по памяти / загрузке процессора / I/O какие показатели? может эта проприетарщина чего то ждёт а железо в это время простаивает. короче говоря прекращайте жрать проприетарный кактус и плакать в век когда переход на открытые технологии столь прост как никогда.

Перечисленное в цитате (с учетом dBase/FoxPro/Clipper) — это функции клиента СУБД. Да, для xBase физически отделить собственно СУБД от клиента тяжело ;) поскольку это библиотечная часть клиента, но логическое разделение от этого никуда не девается.
А путаница, как известно, в головах.

наглядная демонстрация к чему приводит анти unix way

это функции клиента СУБД.

Ещё раз, медленно и по буквам: СУБД – это СИСТЕМА УПРАВЛЕНИЯ базой (базами) данных. Клиент к серверу (если СУБД устроена по технологии клиент-сервер) – НЕОТЪЕМЛЕМАЯ часть СУБД, без которой НЕВОЗМОЖНО управлять БД.

для xBase физически отделить собственно СУБД от клиента тяжело

dBase (II, III и IV) не была построена как клиент-сервер, за остальные не скажу.

прекращайте жрать проприетарный кактус и плакать в век когда переход на открытые технологии столь прост как никогда

Вы никак не поймёте, что переход на другую технологию – это лотерея или предварительный эксперимент, в котором надо убедится, что предлагаемый инструментарий корректно «подхватит» имеющееся оборудование.

Вы не понимаете, что «голая» СУБД никому не нужна, даже если это совместимая со всем 1С или полностью бесплатный PostgreSQL в связке с полностью бесплатным LO Base.

Необходимо «заточить» эту СУБД под нужды конкретного использования. А это опять деньги и время. В том числе и время работников фирмы, которые должны будут написать тех.задание вида «надо кнопочки, которые делают: ….». Например, печатают из приёмной накладной этикетку на Zebra в количестве: 1 шт или в количестве принятого товара, или в количестве из накладной, или в количестве, вводимом оператором.

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

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

Потому все руководствуются принципом: «Хоть как-то работает? Трогать не будем.»

да потому что надо использовать открытые стандарты и открытое ПО. вся суть проприетарного софта раскрыта: тут заставить не смогли печатать ... вызывать спеца ... писать в поддержку разработчика ... что как работает никто не знает ... тьфу.

От количества повторов верность того или иного утверждения не изменится. Ваше мнение понятно, но не принято, повторяться нет смысла.
Ваша СУБД - это АРМ.
СУБД - система управления базами данных - это набор функциональности, обеспечивающий хранение, доступ, извлечение, целостность и непротиворечивость данных.
Все прочее поверх для конкретной БД - есть БД, Клиент, АРМ, готь горшком назови, ничего не изменит.
Применительно к xBase сама возможность сделать USE tbl IN NEW или SELECT * FROM tbl WHWRE ... и т.п. - это СУБД, тот движок, на котором БД работает. А вот конкретный их набор (DDL, DML, интерфейс с ползателем) в клиентском приложении - уже нет.

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

Читайте: доступ, извлечение – это и есть обязанности клиента к серверу БД, являющемуся частью СУБД. То, что представить извлечённое надо в форме, требуемой оператору, самоочевидно.

Возможно, наш спор чисто терминологический.

///СУБД состоит из:

• Ядра. Поддерживает отчетность, отвечает за управление данными в ОЗУ и на внешних накопителях.

• Процессора языка БД. Позволяет оптимизировать запросы на создание и редактирование данных.

• Подсистемы поддержки времени исполнения. Позволяет интерпретировать ПО для поддержки работы с БД, создавать пользовательские интерфейсы взаимодействия с СУБД.

• Вспомогательного ПО. Набор утилит, позволяющих расширить возможности взаимодействия с СУБД (в том числе, и по обслуживанию).

Под «клиентом» я и понимаю часть последнего. При этом следует учитывать, что указанное деление достаточно условно.

Читайте: доступ, извлечение – это и есть обязанности клиента к серверу БД, являющемуся частью СУБД.

Нет. Тот, кто выполняет обращения к БД — СУБД. Тот, кто инициирует обращения к БД — клиент.

Потребовался новый запрос или новый отчет, или иное представление выборки данных, новые таблицы в БД — это все не затрагивает собственно СУБД — саму систему управления. Грубо говоря, всё, для чего вам не нужно патчить тот же FoxPro в части непосредственно доступа к данным, не является СУБД ;-)

Возможно, наш спор чисто терминологический

Возможно. Но спора нет, о терминах вообще нет смысла спорить. Хороша та терминология, которая позволяет систематизировать определяемую область и решать задачи, и плоха та, которая все только запутывает. Вы вольны использовать любую, кто ж вам запретит, например, «СУБД в части движка данных» или «СУБД в части клиентского кода» вместо «СУБД» и «клиент БД», почему нет, удобно же и сразу понятно, о чем речь, и акроним для мебели присутствует.

///СУБД состоит из:

Даже нынешняя русскоязычная вики намного точнее в определении:

Основные функции СУБД

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

Состав СУБД
Обычно современная СУБД содержит следующие компоненты:

• ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию;
  
• процессор языка базы данных, обеспечивающий оптимизацию запросов на извлечение и изменение данных и создание, как правило, машинно-независимого исполняемого внутреннего кода;
  
• подсистему поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД;
  
• сервисные программы (внешние утилиты), обеспечивающие ряд дополнительных возможностей по обслуживанию информационной системы.

Соедините функции с составом, разница с вашим определением станет достаточно очевидна.

я тут половину коментов пока осилил и так ниче не понял, подскажите пжалста, FreeBASIC норм тема?