Состояние экосистемы Common Lisp на 2015 год

Т.е. когда фотоаппарат записывает в только что сделанный снимок данные EXIF, он делает невозможное?

При чем тут фотоаппарат, если мы говорили о вполне конкретном примере - метаданные хранящихся на машине клиента файлов? Каким образом ты будешь эту «согласованность» обеспечивать в БД, если самого файла в БД нет, и он может быть удален/перемещен/изменен без запуска БД?

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

Проблемы начинаются, когда на БД переносится сложная логика выборки и обработки данных, потому что SQL - очень плох именно как _ЯП_.

Для выражения сложной логики и обработки данных в большинстве случаев хватает PL/SQL. Очень простой язык. В качестве бонуса от его использования можно назвать тот факт, что когда для вычисления конечного результата требуется выполнить несколько запросов, данные не нужно гонять от сервера к клиенту для вычислений, потом опять от клиента к серверу. Всё делается на сервере в функции, потом возвращается клиенту один раз. :-)

Какие-либо средства контроля за сложностью в этом языке отсутствуют как таковые.

Зато там контроль над типами есть :-)

а пишут на ЯВУ.

Ахаха :-) Теперь понятно почему ORM. Хибернате же :-)

Ага, они берут информацию о структуре БД прямиком из libastral.

Они ниоткуда не берут информацию. ОниЖеШаблоны. :-) В них просто следует подставить недостающую информацию. Можно из libastral, можно из СУБД :-) Дело хозяйское.

Ты упорно не понимаешь того факта, что у тебя два варианта - либо выразить модель БД в одном месте (шаблонами, классами, еще чем-либо, не важно совершенно) и тогда нет смысла не использовать ОРМ, либо при каждом изменении БД потом пердолить весь код, исправляя вызовы по отдельности.

БД может быть общей на несколько проектов. Мне не нужно выражать модель БД. Мне нужны только те данные из базы, которые следует упаковать в шаблон. Всё. А при каждом изменении БД пересматривать весь код необходимо в любом случае. Хоть с ORM, хоть без ORM. :-) Или у тебя ORM на libastral? :-)

При чем тут фотоаппарат, если мы говорили о вполне конкретном примере - метаданные хранящихся на машине клиента файлов? Каким образом ты будешь эту «согласованность» обеспечивать в БД, если самого файла в БД нет, и он может быть удален/перемещен/изменен без запуска БД?

Так я наоборот говорю, что это бредовая ахинея хранить метаданные о файлах клиентов в БД :-) Я призываю хранить файлы в виде bytea в таблицах БД. Ты не внимательно читал меня :-)

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

Я об этом и говорил. Будь внимателен. :-)

Так я наоборот говорю, что это бредовая ахинея хранить метаданные о файлах клиентов в БД :-)

Так здесь два варианта тогда:

1. не хранить метаданные в БД, а сделать какой-то свой велосипед - плохо

2. хранить файлы клиента в бд - еще хуже

Хибернате же :-)

Хибернате, конечно, говно жуткое.

Для выражения сложной логики и обработки данных в большинстве случаев хватает PL/SQL.

Я и говорю о том, что это _крайне_ плохой язык для подобных задач. Он подходит, если надо быстро хуякс-хуякс и накалякать что-то очень простенькое, строчек на 5, ну на 10 может быть.

Ты вообще плохо понимаешь, зачем нужны ОРМ, видимо. Они не затем, чтобы можно было писать те же запросы, но с каким-то другим уебищным синтаксисом, они затем, чтобы можно было использовать средства декомпозиции хост-языка при описании логики работы с данными. Потому что SQL (в том числе и с расширениями) таковых не предоставляет вообще. Язык действительно, как ты заметил, простой, и хорошо подходит для простых вещей, маленьких систем. При росте системы возникает потребность в наличии средств борьбы со сложностью, чтобы можно было эффективно поддерживать код. Портянки из десятков тысяч строк на скуле поддерживать - ад адовый. И проблема в том, что скуль просто не предоставляет средств для того, чтобы их можно было оформить в каком-то адекватном виде.

Зато там контроль над типами есть :-)

В статических языках тоже есть. И гораздо лучше ;)

ОниЖеШаблоны. :-) В них просто следует подставить недостающую информацию.

И как шаблоны узнают каким образом и какую информацию надо выделить из запроса? ;)

А при каждом изменении БД пересматривать весь код необходимо в любом случае.

конечно же нет. Именно для этого есть ОРМ ;)

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

Ну а откуда шаблон узнает, какие данные к нему пришли меняет сам себя при изменении их формата? ;)

2. хранить файлы клиента в бд - еще хуже

Обоснуй :-)

Во-первых, никакой БД не хватит, потому что клиентов может быть и сто и тысяча и миллион.

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

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

Во-первых, никакой БД не хватит, потому что клиентов может быть и сто и тысяча и миллион.

А еще клиент может быть удаленным.

Ты вообще плохо понимаешь, зачем нужны ОРМ, видимо.

Я прекрасно понимаю, что они не нужны. Совсем :-)

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

Ну и какой такой павлин-мавлин? :-) При написании функции в том же Postgres можно использовать хоть PL/pgSQL, хоть PL/Perl, хоть PL/Python, хоть PL/Scheme, хоть PL/Java, хоть Bash, хоть C.

При росте системы возникает потребность в наличии средств борьбы со сложностью, чтобы можно было эффективно поддерживать код.

Ты этому у Буча что-ли научился? «Борьба со сложностью», хехе :-)

Портянки из десятков тысяч строк на скуле поддерживать - ад адовый.

Это к любому языку относится. В особенности, к цепепе или жаве. :-)

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

Да то же самое, что и в других языках. Раскидывай по файликам и будет тебе счастье :-)

Во-первых, никакой БД не хватит, потому что клиентов может быть и сто и тысяча и миллион.

Это смотря кто ты есть :-) Для БД Гугла это не проблема. :-)

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

Тогда ему БД не нужна.

Тот же плеер в качестве примера - там именно так и происходит, метаданные в БД и файлы в ФС.

Вот уж вздор! В этом случае в БД метаданные не файлов клиентов, а метаданные /музыкальных произведений/, каждое из которых уникально! А вот их /копии/ лежат в виде файлов у клиентов. Это как кэш :-)

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

Скоро к этому и придёт. :-)

А при чем тут я? Мы имеем факт - никто не пишет в БД бизнес-логику кроме парочки упоротых маргиналов вроде тебя.

Кстати, да. Иметь крамольные мысли о бизнес-логике в БД могут только махровые админы и DBA. Хорошо, что к ним никогда не прислушиваются в этих вопросах, а просто посылают нахер. Ибо, как минимум, тестировать код в хранимых процедурах - боль и стыд.

В таблице «проводка» в обоих решениях должно быть только одно поле «аналитика» для каждого из счетов.

Если одно поле, то там должен быть список разнотиповой информации. Технически, конечно можно сделать одну колонку «аналитика», которая ссылается на одноимённую таблицу.

Собственно суть вопроса: фильтрую record.detail3.date > '20150101' (или record.detail[3].date > '20150101'), а в SQL что можно сделать?

Если одно поле, то там должен быть список разнотиповой информации.

Не знаю что ты имеешь в виду под «списком разнотиповой информации». У тебя будет 2 таблицы: «проводка» и «аналитика». В таблице «аналитика» будут храниться сущности иерархии классов «аналитика», каждый из которых может дополнять набор полей родительского класса своими полями. А также будет специальное поле «тип». По уму, должен быть так же триггер (или CHECK, но не очень удобно), который не допустит существование в таблице «аналитика» такой сущности, принадлежащей к одному классу аналитики (по «типу»), которая бы имела данные в столбцах другого подкласса «аналитики» (т.е. все «чужие» поля в сущности с «типом» T будут NULL и это будет обеспечиваться триггером).

Собственно суть вопроса: фильтрую record.detail3.date > '20150101' (или record.detail[3].date > '20150101'), а в SQL что можно сделать?

Пусть даны 2 таблицы «проводка». Насколько я теперь понял, каждая сущность «проводка» обязана ссылаться (хотя бы для простоты) на 3 счёта аналитики (т.е. в таблице «проводка» 3 поля: «а1», «а2», «а3», которые не NULL, ссылаются на сущности разных типов в таблице «аналитика»). Тогда

create view "аналитический_отчёт_по_проводкам" as
  select "проводка".*, "аналитика".*
    from "проводка" "п"
    join "аналитика" "a" on ("п"."а1" = "а"."аид" or
                           "п"."а2" = "а"."аид" or
                           "п"."а3" = "а"."аид");

И далее любой WHERE по потребностям:

select * from "аналитический_отчёт_по_проводкам"
  where "дата_аналитики" > '20150101';

Всё :-)

PS. «аналитический_отчёт_по_проводкам» - имя неудачное. Правильней как-нибудь «проводка_с_аналитикой» :-) Так то лучше.

select * from "проводка_с_аналитикой"
  where "дата_аналитики" > '20150101';

:-)

Иметь крамольные мысли о бизнес-логике в БД могут только махровые админы и DBA.

Ха! А иметь крамольные мысли «шоу бизнесе» в SBCL могут только отпетые маргиналы :-) И что?

Ха! А иметь крамольные мысли «шоу бизнесе» в SBCL могут только отпетые маргиналы :-) И что?

Даже в крамольные мысли о/в SBCL, не столь крамольны, чем мыслишки о хоть каком-то коде в БД.

Я прекрасно понимаю, что они не нужны.

Конечно не нужны. До тех пор пока ты не пишешь ничего сложнее гостевухи.

При написании функции в том же Postgres можно использовать хоть PL/pgSQL, хоть PL/Perl, хоть PL/Python, хоть PL/Scheme, хоть PL/Java, хоть Bash, хоть C.

То есть в итоге выкидываем SQL?

Это к любому языку относится. В особенности, к цепепе или жаве. :-)

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

Да то же самое, что и в других языках. Раскидывай по файликам и будет тебе счастье :-)

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

Это смотря кто ты есть :-) Для БД Гугла это не проблема. :-)

Конечно, проблема.

Тогда ему БД не нужна.

То есть надо для хранения метаданных использовать свой велосипед а БД использовать нельзя?

В этом случае в БД метаданные не файлов клиентов, а метаданные /музыкальных произведений

Которые представлены файлами, все верно.

А вот их /копии/ лежат в виде файлов у клиентов.

Да нет. В БД метаданные, на харде у клиента - файлы.

Скоро к этому и придёт. :-)

Нет, не придет :) Тебе домашнее задание - объяснить, почему ;)

То есть в итоге выкидываем SQL?

Ну это кто как. Я, скорее, Java вместе с потрохами выкину, чем SQL :-)

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

Ну это кто на что учился. :-)

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

А ну ка, расскажи, что за дивные средства такие придумали в других языках, которые эффективнее, чем разделение кода по файликам? :-)

Конечно, проблема.

Нет, не проблема. Это для твоей любимой мелочи пузатой навроде торрент-трекеров проблема, а Гугл на каждый только почтовый ящик готов 10 Гб выделить. :-)

То есть надо для хранения метаданных использовать свой велосипед а БД использовать нельзя?

Ну а зачем кому-то героически преодолевать сложности, создаваемые инструментом? Мазохистов то мало. :-)

Которые представлены файлами, все верно.

А, всё ясно. Кроме как «фаелами» информация больше никак не представима. Её нельзя изменить, нельзя вычислить хэш, и нельзя хранить ни в каком виде, кроме как в «фаеле» :-) Завязывай с торрентами.

Да нет. В БД метаданные, на харде у клиента - файлы.

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

Нет, не придет :) Тебе домашнее задание - объяснить, почему ;)

Ахаха :-)

ссылаются на сущности разных типов в таблице «аналитика»

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

аид    |  тип          |  номер  |  наименование | дата       | ...
--------------------------------------------------------------
1      | номенклатура  |  NULL   |  вентилятор    |  NULL
2      | реализация    |  00006  |  NULL         | 2015-01-01 | ...
....

?

А если нужна, например, только номенклатура, то делаем VIEW с поляем номенклатуры и отбором по типу.

Тогда, да, отбор по полю даты сводится к

select проводка.*
from from проводка
     join аналитика on проводка.а3 = аналитика.аид
where аналитика.дата > '20150101'

Вот только я правильно понимаю, что при таком дизайне придётся делать индексы на (почти) все колонки и процесс добавления строки в таблицу аналитики будет жутко медленный?

При наличии ORM как правило делается по отдельной таблице на вид аналитики, а запрос (сгенерированный) становится

select проводка.*
from from проводка
     join (select аид, дата from аналитика1
           select аид, дата from аналитика9           
           select аид, дата from аналитика15
           select аид, дата from аналитика69) как аналитика
         on проводка.а3 = аналитика.аид
where аналитика.дата > '20150101'

список таблиц, имеющих поле «дата», определяется в модели ORMа.

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

Я сопровождал торговую систему на Informix 4GL. Там количество строк кода просто зашкаливало, но при этом система была вполне сопровождабельная. Кстати, там как раз был решён вопрос с тем «что делать с результатом запроса, если нет ORM». Либо результат запроса — некие данные пользователю, тогда они выводятся пользователю (есть в том «4GL PL/SQL» команда OPEN FORM, ...), либо результат запроса печатная форма, тогда данные склеиваются со строками (подставляются в шаблон) для генерации файла latex или csv.

Скажу честно, сопровождать эту штуку мне было проще, чем фабрики классов на Java (в Java найти место для нужного изменения иногда очень сложно). Кстати, работает оно всё на RedHat Linux.

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

Да. Это самый простой способ физической реализации наследования. Если таблица будет действительно огромной, то в том же Postgres есть возможность делить эту таблицу на много отдельных по определённым критериям (например, до диапазонам id) физических таблиц. :-)

Вот только я правильно понимаю, что при таком дизайне придётся делать индексы на (почти) все колонки и процесс добавления строки в таблицу аналитики будет жутко медленный?

Индексы очень желательно делать на все внешние ключи. В данном случае, их 3 в таблице «проводка». В таблице «аналитика» я пока не виду ни одного индекса, кроме как на столбец «аид» и «дата» (который, может быть даже и не нужен). Насчёт «жутких тормозов» - всё относительно. Надо измерять. :-)

При наличии ORM как правило делается по отдельной таблице на вид аналитики, а запрос (сгенерированный) становится

Опять же, надо измерить. Очень спорно, что этот сгенерированный ORM запрос будет эффективнее, чем в случае, когда имеется одна таблица. Способ физической реализации наследования можно организовать и в виде отдельных таблиц для каждого класса сущностей. У последних должен быть уникальный идентификатор, что легко делается с помощью последовательностей (sequence). Но тогда обязательно должен быть какой-либо генератор запросов, вроде твоей ORM. В принципе, можно написать простенький генератор для таких задач и на стороне СУБД, но дизайн «одной таблицей» сильно удобнее :-)

В таблице «аналитика» я пока не виду ни одного индекса, кроме как на столбец «аид» и «дата» (который, может быть даже и не нужен).

Я имел в виду, что для документа нужен поиск по дате (диапазону дат), для номенклатуры — по наименованию (включая LIKE), для реализации по полям контрагент, склад, организация...

И если хоть один вид аналитики требует поиск по полю, то придётся делать индекс. Так как таблица очень многострочная и поиск перебором станет очень медленный.

+ составные ключи на тип+дата, тип+наименование, тип+контрагент, ...

Очень спорно, что этот сгенерированный ORM запрос будет эффективнее, чем в случае, когда имеется одна таблица

Будет равнозначно, если есть индекс по тип+дата и в единой таблице добавить условие «тип В (...)».

можно написать простенький генератор для таких задач и на стороне СУБД

С таким допущением согласен, что нет разницы: логика внешняя или в СУБД. Разве что в СУБД мы намертво привязываемся к конкретному решению и переход, например, Oracle -> PostgreSQL становится на порядок дороже.

В смысле, вместо одной таблицы будет N^3, где N — число типов для > аналитики?

Union - это примитив для полиморифзма, на нём строится view, дающее полиморфный доступ к полям производных объектов. 3 (6) экземпляров таблицы «любая аналитика» джойнятся к основной. Хотя на самом деле это плохое решение с точки зрения проектирования БД.

То есть getdate(account, detail3) будет делать SELECT из БД на каждый вызов.

Обращение по ссылке в обычном ЯП в SQL воплощается в виде select по первичному ключу. Здесь нечего бояться и нечего улучшать - таковы правила игры. БД можно воплотить как образ в памяти, запись сделать struct-ом, а первичным ключём сделать &x. Тогда получим производительность С, хотя в языке это будет select * from table where id=:id . man create clutster (Oracle).

То есть тот же ORM. Только, возможно, на стороне сервера

Вот именно. Сервер может (почти) всё.

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

Угу. Потому что REPL и ещё хорошая рефлексия - таблицы зависимостей классов и функций между собою.

Я имел в виду, что для документа нужен поиск по дате (диапазону дат), для номенклатуры — по наименованию (включая LIKE), для реализации по полям контрагент, склад, организация...

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

И если хоть один вид аналитики требует поиск по полю, то придётся делать индекс.

Ну и что. В Postgres, например, есть поддержка частичных индексов. При создании таких индексов нужно указывать условие, только при выполнении которого значение индексируемого столбца попадёт в индекс. Т.е. можно было бы придраться к размерам индексов одной общей таблицы, дескать, строк очень много, и все индексы также будут большими. Ан нет :-)

Так как таблица очень многострочная и поиск перебором станет очень медленный.

Ну как так можно пальцем в небо говорить о «медленно»? Ты попробуй :-)

Будет равнозначно, если есть индекс по тип+дата и в единой таблице добавить условие «тип В (...)».

Теоретически. А на практике надо посмотреть :-)

С таким допущением согласен, что нет разницы: логика внешняя или в СУБД. Разве что в СУБД мы намертво привязываемся к конкретному решению и переход, например, Oracle -> PostgreSQL становится на порядок дороже.

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

есть поддержка частичных индексов

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

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

Ересь YAGNI! Так можно дойти до того, что ООП вообще не надо. Так как полезна только при возможных изменениях.

Ересь YAGNI! Так можно дойти до того, что ООП вообще не надо.

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

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

Сам видел. Больница переходила с Oracle на Firebird. Деньги в бюджете кончились.

С того же лиспа на C++ или Java часто переходили чтобы не платить за каждую установку.

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

Полностью согласен.

Сам видел. Больница переходила с Oracle на Firebird. Деньги в бюджете кончились.

Ладно бы с Oracle на Postgres, это было бы понятно... И чего только в жизни не бывает :-)

С того же лиспа на C++ или Java часто переходили чтобы не платить за каждую установку.

В смысле, с LispWorks? Или кому не хотелось платить? :-)

В смысле, с LispWorks?

Allegro, Lispworks. Если решение получилось удачное и надо его тиражировать на несколько подразделений/филиалов/предприятий.

А с учётом использования коммерческих компонент «с максимальной отдачей, ибо деньги уплОчены», получается, что готовое решение по трудозатратам переписать на C++/Java едва ли не дешевле, чем на SBCL (GUI, сеть, БД — всё другое и в SBCL неясного качества).

получается, что готовое решение по трудозатратам переписать на C++/Java едва ли не дешевле, чем на SBCL (GUI, сеть, БД — всё другое и в SBCL неясного качества)

А интересно, какой-нибудь джидай превращал какое-нибудь GUI-шное приложение, например, с LispWorks или с Qt в WEB-приложение на SBCL + Hunchentoot + Parenscript + Postmodern? :-)

А ну ка, расскажи, что за дивные средства такие придумали в других языках, которые эффективнее, чем разделение кода по файликам? :-)

Полиморфизм и инкапсуляцию, в том или ином виде (ООП, модули, типы, не важно - реализаций много, важно, что ничего этого в скуле нет).

Ну это кто на что учился. :-)

Так какая разница кто на кого учился? Скуль простой, на нем любая обезьянка сможет писать.

а Гугл на каждый только почтовый ящик готов 10 Гб выделить. :-)

Гугл готов выделить на каждый почтовый ящик по 10гб только и исключительно по той причине, что 99.9% не используют и гигабайта. Мы же говорим о террабайтах информации на рыло, что-то многовато. Алсо, тратить деньги на датацентры лишь за тем, чтобы иметь возможность зачем-то (зачем, кстати? какая в этом польза вообще?) хранить данные в БД (и какой БД, кстати? реляционные СУБД не способны масштабироваться в ширину, это фундаментальное ограничение, так что никаких датацентров со скулями в природе просто не существует) никто не станет, конечно же.

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

А какие сложности? Метаданные хранятся БД, файлы - в ФС, никаких сложностей :)

А, всё ясно. Кроме как «фаелами» информация больше никак не представима. Её нельзя изменить, нельзя вычислить хэш, и нельзя хранить ни в каком виде, кроме как в «фаеле» :-) Завязывай с торрентами.

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

Да, в случае с теми же торрентами, это так.

Причем тут торренты если мы говорим о проигрывателе? :cry:

Полиморфизм и инкапсуляцию, в том или ином виде (ООП, модули, типы, не важно - реализаций много, важно, что ничего этого в скуле нет).

Ахаха :-) Что же тогда в любом дереве исходников, в любом репозитории проектов на любом языке с хвалёной инкапсуляцией и полиморфизмом, включая C++, Java, C#, Ruby, включая Common Lisp, Racket, Clojure, всегда десятки десятков, если не тысячи файликов? :-) Я понимаю, что Страуструп (писал в своей «Дизайн и эволюция C++») и ты мечтаете, что когда-нибудь будет такая IDE, где программист будет размышлять и оперировать только пространствами имён и классами, не думая о файлах. :-) Но это всё мечты и фантазии, а на сегодняшний день, как и 50 лет тому назад, разделение по файлам - самый эффективный способ упорядочивания информации, включая исходные тексты программ :-)

Скуль простой, на нем любая обезьянка сможет писать.

Ну так я на нём и пишу, потому что он простой. Я же не херой, воюющий с ветряными мельницами во имя самоутверждения и самолюбования. Мне чем проще, тем лучше :-)

Я сопровождал торговую систему на Informix 4GL.

Ну это не SQL, это скорее скриптовый язык, который умеет в raw sql запросы внутри себя.

Если я правильно понял, какого рода была система - то это как раз то редкое исключение из правил (сама логика простая, но ее тупо _много_, при этом абстрагироваться особо не от чего, например, надо уметь делать миллион отчетов при том все они разные и ничего общего не имеют - в этом случае действительно «распихать по файлам» прокатывает).

Гугл готов выделить на каждый почтовый ящик по 10гб только и исключительно по той причине, что 99.9% не используют и гигабайта.

Т.е. Гугл(!) не готов, по твоему, к ситуации, если все пользователи забьют свои почтовые ящики под завязку? :-) Ты себя слушаешь вообще? :-)

Мы же говорим о террабайтах информации на рыло, что-то многовато.

Да это титька тараканья :-) Терабайты, хехе :-)

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

Это ты так думаешь :-) Я бы тоже не хотел всей этой глобализации, но... :-)

В хешах можно хранить только сертификат, а не саму информацию.

Тебя пучит что-ли? Кто говорил, что в хешах можно хранить саму информацию? :-) Я говорил про уникальность информации, которая определяется хешем. Т.е. sha256sum «фаел» :-)

Ну это не SQL, это скорее скриптовый язык, который умеет в raw sql запросы внутри себя.

Синтаксически это вариация PL/SQL. Всё, кроме форм, в нормальной БД можно бы запихать в хранимые процедуры. Современный вариант выглядит так: https://ru.wikipedia.org/wiki/Oracle_Forms

сама логика простая, но ее тупо _много_

Это описание применимо почти к любой бизнес-логике. Поэтому бизнес-логика в SQL — ничего необычного.

при этом абстрагироваться особо не от чего, например, надо уметь делать миллион отчетов при том все они разные и ничего общего не имеют

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

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

Синтаксически

Не ну мы же не синтаксис обсуждаем. А то так и LINQ _синтаксически_ вариация SQL.

Это описание применимо почти к любой бизнес-логике. Поэтому бизнес-логика в SQL — ничего необычного.

Ну, у нас, видимо, разный опыт.

Вот ООП действительно там тяжело приткнуть

ООП это метод, а не самоцель, так что если ООП не притыкается это не значит что ту же задачу нельзя решать другими способами :)

Если решение получилось удачное и надо его тиражировать на несколько подразделений/филиалов/предприятий.

Если Lispworks, просто пересылаешь им бинарник.

Если Allegro - ССЗБ. Надо читать лицензию ПЕРЕД покупкой.

Т.е. Гугл(!) не готов, по твоему, к ситуации, если все пользователи забьют свои почтовые ящики под завязку? :

Конечно же, не готов. Это элементарно доказывается: в 2012 году сервисом пользовалось 420кк человек (сейчас, скорее всего, будет много больше, но возьмем за оценку), на ящик выделяется 15гб на данный момент, 420кк*15гб=6.3ккк гб, то есть более 6 эксабайт.

Это ты так думаешь :-)

Это не я так думаю, это все так думают. Ну, кроме 3.5 маргиналов.

Я говорил про уникальность информации, которая определяется хешем. Т.е. sha256sum «фаел» :-)

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

Это элементарно доказывается
то есть более 6 эксабайт.

И что ты этим доказал? :-)

Это не я так думаю, это все так думают. Ну, кроме 3.5 маргиналов.

Ахаха :-)

А при чем тут уникальность информации, если пользователю нужна _сама_ информация?

Причём тут пользователь, если я всего-то лишь говорю, что в БД музыкальных произведений разумно хранить метаданные самих произведений, уникальность которых определяется хешем, а не метаданные «фаелов» клиента? :-) Ну да, какая-то часть этих произведений лежит у клиента в виде «фаелов», но метаданные то произведений :-)

Кроме того, какой смысл заменять информацию на ее хеши, если хеш - это метаданные?

Ты сам с собой уже разговариваешь? :-) Я не знаю какой в этом смысл :-)

В результате если хранить в БД хеши, то мы остаемся в модели метаданные в БД, файлы у пользователя на винте, лол.

Верно. А файлы - всего лишь копии информации из первоисточника, метаданные которой и хранятся в БД. :-)

Я вот только никак не пойму. Какое отношение все эти твои рассказы про «фаелы» клиента и плееры, которые берут метаданные из удалённой БД, имеют к первоначальной надуманной monk'ом проблеме (здесь):

Ну ладно, пусть будет (select (f file) (where (and (> (size f) 1000000) (file-exist-p (filename f)))). Или наличие файла на клиентской машине тоже в хранимую процедуру запихнешь?

Походу, юноша, ты потерялся в своём потоке сознания :-)

И что ты этим доказал? :-)

То есть, по-твоему, кроме работающих датацентров гугла, которые в совокупности как раз и дают примерно такой (с точностью до порядка) объем информации, гугл имеет еще столько же «секретных датацентров» где-то, которые находятся в замороженном состоянии и упорно ожидают того момента, когда вдруг каждый пользователь захочет забить в ящик все 15 гб? :)

Причём тут пользователь, если я всего-то лишь говорю, что в БД музыкальных произведений разумно хранить метаданные самих произведений, уникальность которых определяется хешем, а не метаданные «фаелов» клиента?

Потому что пользователь будет проигрывать фаелы, а не произведения.

Ну да, какая-то часть этих произведений лежит у клиента в виде «фаелов», но метаданные то произведений :-)

Вообще-то, нет. Точнее, это метаданные треков (а не произведений и не файлов). Они могут лежать и в одном файле, конечно, это особой роли не играет. Суть в том, что два одинаковых произведения в разных файлах будут разными треками, которые могут отличаться, например, форматом, качеством, видом исходника (сд, винил, САСД и т.д.) и другими подобными параметрами.

Кроме того, пользователя интересуют как раз только те произведения, что лежат у него в виде фаелов и только они.

Ты сам с собой уже разговариваешь? :-) Я не знаю какой в этом смысл :-)

Так ты же это предложил. Зачем ты предлагаешь вещи, смысла которых и сам не знаешь?

Верно. А файлы - всего лишь копии информации из первоисточника, метаданные которой и хранятся в БД. :-)

Конечно же нет.

Я вот только никак не пойму. Какое отношение все эти твои рассказы про «фаелы» клиента и плееры, которые берут метаданные из удалённой БД, имеют к первоначальной надуманной monk'ом проблеме (здесь):

Самое прямое. Просто ты плохо разбираешься в вопросе, по-этому тебе приходится объяснять на пальцах, чтобы было совсем просто. Еще раз, по порядку:

1. у клиента есть информация

2. для этой информации есть набор метаданных

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

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

То есть, по-твоему, кроме работающих датацентров гугла

По-моему, если Гугл выделяет 15 Гб лично мне, то я могу рассчитывать на свои 15 Гб. И так каждый может думать, ибо Гугл каждому даёт 15 Гб. И зачем Гуглу просто так обещать всем по 15 Гб, если ему заведомо известно, что всем он их дать не сможет? Это тебе не какая-то шарага, ты уж не сомневайся, и не позорься такими вот рассуждениями :-)

Потому что пользователь будет проигрывать фаелы, а не произведения.

Если пользователь будет проигрывать фаелы, а не произведения, то зачем ему вообще далась какая-то удалённая БД с метаданными, тугодум ты наш :-)

Вообще-то, нет. Точнее, это метаданные треков (а не произведений и не файлов). Они могут лежать и в одном файле, конечно, это особой роли не играет. Суть в том, что два одинаковых произведения в разных файлах будут разными треками, которые могут отличаться, например, форматом, качеством, видом исходника (сд, винил, САСД и т.д.) и другими подобными параметрами.

Глаза ты мне не открыл :-)

Конечно же нет.

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

Самое прямое. Просто ты плохо разбираешься в вопросе, по-этому тебе приходится объяснять на пальцах, чтобы было совсем просто. Еще раз, по порядку:

1. у клиента есть информация 2. для этой информации есть набор метаданных Ахаха :-) Да неужели? :-) Это вам так в бурсе объясняли? :-)

Ты зачем-то (зачем? ты так и не ответил) предлагаешь либо писать для хранения метаданных свой велосипед

Где я предлагал писать велосипед? Покажи :-)

либо тратить совершенно невразумительное количество ресурсов на хранение информации пользователя и ее доставку ему.

Ты в каком году застрял вообще? :-) Не, ну конечно же, задроты по старинке качают свои mp3 с пираЦких сайтишек. В то же время как абсолютное большинство закачивают и смотрят гигантские количества материалов с Youtube, с Одноклассников, с ВКонтакте, покупают музыку в iTunes Store и т.д. Так что для владельцев ресурсов «тратить совершенно невразумительное количество ресурсов на хранение информации пользователя и ее доставку ему» - не проблема. :-)

При этом снижая с точки зрения пользователя качество работы системы.

Ну да, я понял, у тебя до сих пор Dial-Up и модем US Robotics :-) Ахаха :-)

По-моему, если Гугл выделяет 15 Гб лично мне, то я могу рассчитывать на свои 15 Гб.

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

Если пользователь будет проигрывать фаелы, а не произведения, то зачем ему вообще далась какая-то удалённая БД с метаданными

Потому что он хочет знать, что проигрывает, тугодум ты наш.

Глаза ты мне не открыл :-)

Как видно, открыл.

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

И я о легальных. Купил музыку, сделал оцифровку.

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

Кто сливает, что сливает? Ты бредишь, по-моему.

1. у клиента есть информация 2. для этой информации есть набор метаданных Ахаха :-) Да неужели? :-) Это вам так в бурсе объясняли? :-)

Это так есть по факту. Дано нам в наблюдениях. Точно так же как то, что утром солнце встает, а на закате - садится.

Где я предлагал писать велосипед? Покажи :-)

А что ты предлагаешь делать в том случае, когда хранить данные в бд нельзя просто физически (то есть ВО ВСЕХ рассматриваемых)?

Ты в каком году застрял вообще? :-) Не, ну конечно же, задроты по старинке качают свои mp3 с пираЦких сайтишек. В то же время как абсолютное большинство закачивают и смотрят гигантские количества материалов с Youtube, с Одноклассников блаблабла

Ну то есть ты готов тратить столько же сколько тратят на поддержку серверов и откаты за трафик гугл, маилру, яндекс и т.д... ради чего? Что ты за это получаешь?

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

И это работает исключительно потому, что практически никто эти 15гб не использует, еще раз.

Любой может убедиться в моей правоте - достаточно зайти в почтовый ящик от Гугла и увидеть, что Гугл предоставляет 15 Гб. А у тебя доказательства есть, что «никто эти 15гб не использует»? Нет? Тогда свободен. :-)

Потому что он хочет знать, что проигрывает, тугодум ты наш.

Вообще-то формат MP3 содержит тэги ID3, предназначенные для хранения полной информации и произведении :-) Так что никому, кроме таких тугодумов как ты, твоя бредовая БД с метаданными о трэках с пираЦких сайтов ненужна :-)

Как видно, открыл.

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

Кто сливает, что сливает? Ты бредишь, по-моему.

Тугодум и есть. :-) Вообще-то, пираЦкий контент хранить противозаконно. И если какой-то тугодум воспользуется хрен пойми ради чего каким-то плеером для воспроизведения пираЦкого контента, то он явно «спалится» :-)

Это так есть по факту. Дано нам в наблюдениях. Точно так же как то, что утром солнце встает, а на закате - садится.

Жесть... :-)

А что ты предлагаешь делать в том случае, когда хранить данные в бд нельзя просто физически (то есть ВО ВСЕХ рассматриваемых)?

Профессию менять :-) Всё равно толком ничего не получится.

Ну то есть ты готов тратить столько же сколько тратят на поддержку серверов и откаты за трафик гугл, маилру, яндекс и т.д... ради чего? Что ты за это получаешь?

Все вышеперечисленные компании тратят на поддержку из прибыли и для прибыли. Я готов тратить столько, сколько нужно будет, чтобы поиметь прибыль. Если дорасту до Гугл, то столько же и буду тратить, если не больше :-)

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

Зачем ты мне нужен, дорогой заказчик, если я сам себе заказчик и сам себе работодатель? :-)