Каталогизация записей

Цитата:

---

Сообщение от Алексей

можно ли где скачать программу для ведения каталога записей? (не путать с jukebox'ами и т.п.!) Или хоть название.

---

Могу разве что выложить свой вариант MS Access'овской базы, которую сам делал для своего каталога. Она не очень правильная с точки зрения теории построения баз, но я ей пользуюсь для ведения своего каталога записей.

Не знаю, насколько это красиво и функционально. Смотрите сами. Для использования нужен MS Access 2002. Под ссылкой - 700 KB. 8)

Вероятно, к этой базе надо делать help, но мне просто некогда этим заниматься. Но для начала даю маячок: в этой базе каждое произведение нумеруется (там есть поле "код"). Формат такой: LL-GGGG/NN где LL - тип носителя (напр., CD - компакты, TP - кассеты, VN - пластинки и т.п.), GGGG - номер носителя (предполагается, что все диски пронумерованы и выставлены один за другим), NN - номер пьесы на диске. Таким образом мы получаем однозначный идентификатор для любой пьесы. Иначе говоря, значимое поле только одно - этот самый код, во все остальные можно вообще ничего не вводить (иногда бывает, не знаешь опуса или еще чего-то).

Эх...Хочется красивую и "продвинутую" программку. Главное - поиск-выборка. Чтобы и сольные опусы, и оперы можно было занести. И выбирать потом по любому полю. И записей будут несколько тысяч.
Самому делать некогда :-(.

Уже давно есть планы сделать такую программку. Мысли есть... И прототип даже имеется! Ничего точно обещать не могу, но надежду дарю ;)

Цитата:

---

Сообщение от Serg

Эх, каталог, каталог… У самого бродят такие мысли на счет каталога. Вам это очень срочно? И как Вы думаете, много ли есть людей, заинтересованных в подобных каталогах? Есть тут одна задумка, точнее, практически, готовая программа…

---

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

Привет!

Цитата:

---

Сообщение от boris

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

---

Борис, это Вы мне? Видите ли в чем дело…

Есть некоторая оболочка, которая позволяет работать с текстовыми БД, позволяет атрибутировать, и классифицировать документы, причем, довольно гибко. Т.е. Классификаторов может быть много и неограниченной глубины вложенности. Позволяет производить сложный (совокупный) поиск как по атрибутам, так и по самому тексту с учетом морфологии русского языка. Программа может гибко настраиваться как на состав атрибутов: их количество, и их свойства (число, строка, дата etc), так и на способ отображения. Возможно делать свои подшивки и закладки. Возможны гипертекстовые ссылки, как внутри базы, так и во внешний мир, так же ссылки на внешние модули, типа проигрыватель MP3 etc

Интересно? Продолжать?


В общем, оболочка эта – очень мощный инструмент, для просмотра БД, и используется во многих продуктах, некоторых фирм. Сборники правовых документов… годовые подписки журналов, газет… скажем, «Независимая газета» так себя издает. На самом деле, может быть все что угодно.

Но. Есть одно но. Вообще-то, до сих пор юзеру отдавалась только оболочка для просмотра БД, и сама БД. Ведение БД до сих пор представляло из себя довольно… ну так скажем, технологически, весьма, непростую задачу, которая осуществлялась операторами БД.

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

Извините, по-многу печатать не могу - мало времени. Продолжение следует…


Ну, ладно… про средство ведение БД с удобным и прозрачным интерфейсом я сказал. Существует, однако, как ниже сказал Борис, еще и задача конфигурации БД. В общем, задача эта совершенно нетривиальная для обычного юзера, даже при наличии, опять таки удобного интерфейса (он, кстати, имеется). Обычному меломану, ИМХО, связываться с этим совершенно не имеет смысла. Ну, это все равно, как на КРАЗе в час-пик к теще на блины поехать.

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

Serg

Цитата:

---

Сообщение от Serg

Привет!
Борис, это Вы мне? Видите ли в чем дело…

---

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

Цитата:

---

Сообщение от boris

Цитата:

---

Сообщение от Serg

Привет!
Борис, это Вы мне? Видите ли в чем дело…

---

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

---

Я там отредактировал свое предыдущее сообщение, что бы все компактно лежало.

Про деланье своей базы сейчас расскажу.

Цитата:

---

Сообщение от boris

В любом случае - спасибо. Если нужно место - могу положить у себя, может, кто-то скачает, кому надо.

---

Вот, на счет положить, так же разговор особый... несколько позже.

Serg

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

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

Привет!

Цитата:

---

Сообщение от boris

Я думаю, что эта программа в том виде, в котором Вы ее описали, вряд ли может представлять интерес для коллекционеров. Скорее, действительно, имеет смысл сделать какой-то шаблон, с которым все потом уже будут работать.

---

Я просто описывал некоторые возможности оболочки, причем, далеко не все. Например, я не упомянул, что один документ может принадлежать одновременно разным пунктах одного классификатора. Как аналог – в Юниксе документ может лежать в разных папках. Т.е. скажем, если на диске записан, к примеру, Брух и Дебюсси (бред, на самом деле выпускать такие диски), то найти будет можно как через пункт «Романтизм», так и «Импрессионизм». Так же я не упомянул, что однотипные атрибуты – множественные. Скажем, если вышеупомянутый Брух был записан в 67 г., а Дебюсси в 68, то в поле «дата записи» ставятся два независимых значения, а найти можно как в отдельности по любому значению, так и «67 ИЛИ 68», или «67 И 68».

Безусловно, речь может идти только о конечной конфигурации, потому как отдавать, просто, систему подготовки и просмотра БД невозможно по ряду причин. Во-первых, простому юзеру будет крайне тяжело самому сконфигурировать… Ну это все равно что сказать: Вам нужена программа-каталогизатор? Их есть у меня. Вот вам C++, позволяет сделать все что угодно. Во-вторых, это ПРОФЕССИОНАЛЬНЫЙ, весьма, универсальный инструмент. В общем, понятно… :-)

Цитата:

---

Сообщение от boris

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

---

Борис, Вы - музыкант или программист? :-) Вы очень точно понимаете основную проблему программистики: грамотная постановка задачи – 50% решения этой задачи. :-)

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

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

Ой, я боюсь, что я сейчас окончательно народ запугаю! :-) Не, на самом деле, снаружи все просто. :-)

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

Т.е. я еще раз хочу подчеркнуть, что главное – постановка. Сама конфигурация – работа на день – два.

Цитата:

---

Сообщение от boris

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

---

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

С другой стороны, всегда существовало такое понятие как Бета-тестирование :-) (В данном случае, речь не идет о бета-версии, падающей каждые полчаса. Речь идет о программной оболочке, работающей уже многие годы.) Опять таки, есть такое понятие как авторские экземпляры… Помощники в постановке - так же соавторы… :-)

В общем, жду продолжения беседы.

Serg

Привет!

Общая концепция для обсуждения:
Программа должна быть ориентирована на запись опуса как единицу хранения. Атрибуты опуса – композитор, номер опуса и его тональность (желательно записать тональность в справочник в нотациях разных стран), автор редакции опуса, дирижер, оркестр, исполнители (выбор из списка), инструменты (выбор из списка), дата и место записи как текстовое поле. Можно еще всяческие комментарии, текстовые поля с рецензиями (отсканированными и самостоятельно написанными).
Соответственно подчиненные справочники – люди (один и тот же человек может выступать как композитор и дирижер, или работать на разных инструментах, например), оркестры.

Несколько записей опусов могут быть объединены в один носитель. Атрибуты носителя – тип (78, 45, 33, CDDA, SACD,DVDA), название, фирма издатель (справочник) и номер в каталоге фирмы-изготовителя (возможно указание нескольких альтернативных производителей и нескольких альтернативных номеров), дата издания, Фирма-изготовитель и дата изготовления, если есть. Можно еще предусмотреть фотку с обложки и комментарий.
Таким образом «Гольдбергские вариации» в записи Г.Гульда в такой базе могут быть представлены информацией о 2 х записях разных лет, представленных соответственно - 2-мя .. 3-мя виниловыми оттисками, 2-мя CDDA и 1м SACD.

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

А может вообще все каталоги держать он-лайн?

Вот такой каталогизатор-большой брат.

Удачи.

Цитата:

---

Сообщение от Genn

Соответственно подчиненные справочники – люди (один и тот же человек может выступать как композитор и дирижер, или работать на разных инструментах, например)

---

Для одного человека в разных качествах будет одна или несколько записей в справочнике людей?

Цитата:

---

Сообщение от Genn

, оркестры.

---

...ансамбли? Или ансамбль - это несколько людей?

Как обладатель довольно большой коллекции и давний пользователь своей собственной базы на Access выскажу несколько соображений:
- база должена быть простой, потому что чем сложнее структура, тем больше времени требуется на занесение информации о новом диске, а процесс этот интересен только в самом начале (первая сотня CD ;) ).
- база должна вестись на англ. языке, потому что можно спятить, придумывая русский эквивалент фамилиии типа Herreweghe :) . Кроме того, в случае англ. языка можно пользоваться информацией о диске из интернета. Я, как правило, беру описание из Gramophone. В случае оперы или многодискового комплекта это экономит много времени.
- в идеале – стараться пользоваться стандартными возможностями поиска и/или составления запросов, предоставляемыми продуктами Microsoft. Этих возможностей обычно хватает.
Если делается пользовательская оболочка, то лучше обойтись минимумом программирования. Часто программы, написанные под ранними версиями не будут без переделки работать с новыми версиями.

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

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

Цитата:

---

Сообщение от SN

Как обладатель довольно большой коллекции и давний пользователь своей собственной базы на Access выскажу несколько соображений...

---

Все эти соображения хороши только при использовании Access. И то некоторые из них спорны :) А здесь обсуждается создание чего-то нового, не связанного с Access.

Цитата:

---

Сообщение от Genn

я предполагаю, что запись на одного человека одна

---

Тогда сложно будет делать запрос по одному человеку, играющему на рояле и отдельно по нему же, но играющему на баяне :)

Eugen писал:

Цитата:

---

Все эти соображения хороши только при использовании Access. И то некоторые из них спорны

---

Я, конечно, не ношу гордого звания 'Опытный IT-специалист', но с десяток лет проработал программистом, пока не надоело. А в чём слабость моих соображений?

Хотел отмолчаться ;) но...

Дело в том, что как человек, не два и не три года занимавшийся базами данных, я бы эту штуку легко сваял на Visual Basic + Access :oops:
Но, как здесь кто-то уже заметил (невольно), проблема весьма непростая, так как совершенно плохо укладывается в модель традиционных реляционных таблиц (баз данных). Тут, скорее, нужна сетевая топология (простите уж, не-программисты).

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

(Спасибо за внимание :oops: )

(Serg, а можно всё-таки с Вами лично связаться на предмет...?)

Привет!

Цитата:

---

Сообщение от SN

- база должена быть простой, потому что чем сложнее структура, тем больше времени требуется на занесение информации о новом диске, а процесс этот интересен только в самом начале (первая сотня CD ;) ).

---

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

Цитата:

---

Сообщение от SN

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

---

Я замучаюсь набивать в транслите фамилию «Понькин». Любой язык допустим, однако, если юзер хочет что бы при поиске как по «Rachmaninov», «Rachmaninoff», так и по "Рахманинов" находились все Рахмаманиновы, юзер обязан все эти транскрипции занести в справочник композиторов, ну а при занесении очередной единицы хранения «опус», привязать его ко всем трем записям в справочнике «Композиторы».

Единственная тонкость с русским языком. Как я уже говорил, поиск по тексту, в данном случае это аннотация, либо сопроводительная статья, либо просто статья, осуществляется с уретом русской морфологии. Т.е. «идти» и «шел» - одно слово – разные времена. Те слова которые не опознаются по словарю, кстати, весьма и весьма большому, индексируются как «иероглифы», т.е. as is. Все нерусские слова – иероглифы. Увы, увы… сделать с этим я ничего не могу. Английский словарь имеется, но это стоит весьма немалых денег… В общем, когда ни будь возможно…

Цитата:

---

Сообщение от SN

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

---

А вот этого, увы, не будет в ближайшее время. Т.е. автоматическая качалка из Интернета – задача, довольно, трудоемкая.
Ручками, господа, ручками…

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

Цитата:

---

Сообщение от SN

- в идеале – стараться пользоваться стандартными возможностями поиска и/или составления запросов, предоставляемыми продуктами Microsoft. Этих возможностей обычно хватает.

---

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

Цитата:

---

Сообщение от SN

Если делается пользовательская оболочка, то лучше обойтись минимумом программирования. Часто программы, написанные под ранними версиями не будут без переделки работать с новыми версиями.

---

Пользовательская оболочка готова… почти.
NT, ХP и прочие устроят?
Программа, надо сказать, довольно жручая при поиске по определенным запросам. (Быстродействие процессора) Но там где работает Access все лётает без проблем, как правило.

Serg

Цитата:

---

Сообщение от SN

Я, конечно, не ношу гордого звания 'Опытный IT-специалист'

---

Прекрасно понимаю Вашу иронию, но Вы тоже должны понимать, что это не более чем шутка! :P

Цитата:

---

Сообщение от SN

А в чём слабость моих соображений?

---

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

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

И ещё не совсем понял фразу: "стараться пользоваться стандартными возможностями поиска и/или составления запросов, предоставляемыми продуктами Microsoft".
Какие продукты кроме Access имеются в виду?

Цитата:

---

Сообщение от Алексей

Но, как здесь кто-то уже заметил (невольно), проблема весьма непростая, так как совершенно плохо укладывается в модель традиционных реляционных таблиц (баз данных)

---

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

Цитата:

---

Сообщение от Алексей

На пальцах так:
Единица хранения может содержать много произведений (с разными исполнителями).
Произведение может размещаться на нескольких единицах хранения.
Произведение может иметь одного исполнителя, а может - десятки (N штук).
И т.п.
А теперь попробуйте нарисовать прямоугольную таблицу, в которую всё это легко влезет.

---

А зачем рисовать прямоугольную таблицу? С таким подходом вообще реляционными методами никакую задачу не решишь :) Нарисуйте три - Произведение, Исполнитель, Единица хранения. Между ними связи "многие ко многим" - и всё!

Привет.

Цитата:

---

Сообщение от Eugene

Цитата:

---

Сообщение от Genn

я предполагаю, что запись на одного человека одна

---

Тогда сложно будет делать запрос по одному человеку, играющему на рояле и отдельно по нему же, но играющему на баяне :)

---

Заводим справочник "инструменты". Юзер внесет пункты: cкрипичная музыка, баянная музыка etc. Так-с... Кто ни будь упоминал его? В запросе объединяем Сидоров и Баян.

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

Что касается персоналий, то тут не все так просто. Березницкий-скрипач и Березницкий-альтист – одно лицо, (модераторы, этично ли, что я упомянул реального человека?) но если он еще и музыку будет писать, то, ИМХО, это будет другое лицо.
Справочники персоналий я вижу такие:
1)Исполнители. Сюда относятся как солисты, так и дирижеры, так и названия коллективов и оркестров.
2)Композиторы
3)Звукоинженеры.

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

Мда, вопрос… Что скажете?

Цитата:

---

Сообщение от Алексей

Дело в том, что как человек, не два и не три года занимавшийся базами данных, я бы эту штуку легко сваял на Visual Basic + Access :oops:
Но, как здесь кто-то уже заметил (невольно), проблема весьма непростая, так как совершенно плохо укладывается в модель традиционных реляционных таблиц (баз данных). Тут, скорее, нужна сетевая топология (простите уж, не-программисты).

---

Ты знал, ты знал!!! (c) анекдот про Гиви.

Используется RE-грамматика – несколько более продвинутый вариант сетевой топологии. В переводе на русский общепонятный – грамматика «сущность-связь». Гыыыыы!

Цитата:

---

Сообщение от Алексей

Единица хранения может содержать много произведений (с разными исполнителями).

---

Самый темный вопрос для меня на сегодняшний день. У меня есть понятие «единица хранения» и есть «единица поиска». Единица поиска немного крупнее, чем хранения. Т.е. если как сказал Genn единицей хранения должен быть опус (я с ним согласен в этом), и мы несколько опусов объединяем в «носитель», то единицей поиска будет «носитель».

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

Цитата:

---

Сообщение от Алексей

Произведение может размещаться на нескольких единицах хранения.

---

Не понял, поясните.

Цитата:

---

Сообщение от Алексей

Произведение может иметь одного исполнителя, а может - десятки (N штук).

---

Хоть сто, хоть ни одного…

Цитата:

---

Сообщение от Алексей

(Serg, а можно всё-таки с Вами лично связаться на предмет...?)

---

Можно разумеется. :-)

Serg

Цитата:

---

Сообщение от Serg

Что касается персоналий, то тут не все так просто. Березницкий-скрипач и Березницкий-альтист – одно лицо, (модераторы, этично ли, что я упомянул реального человека?) но если он еще и музыку будет писать, то, ИМХО, это будет другое лицо.
Справочники персоналий я вижу такие:
1)Исполнители. Сюда относятся как солисты, так и дирижеры, так и названия коллективов и оркестров.
2)Композиторы
3)Звукоинженеры.

---

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

Цитата:

---

Eugen писал(а):
Прекрасно понимаю Вашу иронию, но Вы тоже должны понимать, что это не более чем шутка!

---

Да я, в общем, тоже по-доброму ;) Раз должен, так и буду понимать :)

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

Eugen писал:

Цитата:

---

в общем случае сложность занесения информации в базу не зависит от сложности её структуры

---

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

Цитата:

---

Какой язык пользователь захочет использовать, такой и должен быть.

---

Это конечно. Но давайте смотреть реально - подавляющее большинство дисков зарубежного производства, а фамилии многих из исполнителей не имеют сложившегося русского написания. Будем придумывать кто во что горазд? Вон у Бориса в дирижерах (да простит мне отец-основатель это буквоедство :) ) читаем: Шаилли, Рикардо. Это имелся ввиду Riccardo Chailly. Вообще-то в этом случае есть устойчивый вариант - Шайи, но встречался мне и вариант Челли. Может лучше и проще Понькина латиницей?

Цитата:

---

Какие продукты кроме Access имеются в виду?

---

Подразумевались все-таки возможности Access. Но в простейшем случае можно вообще обойтись Excel'ем. Из Access удобно слить каталог в Word и красиво распечатать :) . Для продвинутых - SQL Server.

Цитата:

---

Сообщение от SN

Насколько бы ни был совершенен пользовательский интерфейс, это не избавит от необходимости ввода информации. Как говорится, сколько введешь, столько и найдешь.

---

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

Цитата:

---

Вон у Бориса в дирижерах (да простит мне отец-основатель это буквоедство :) ) читаем: Шаилли, Рикардо. Это имелся ввиду Riccardo Chailly. Вообще-то в этом случае есть устойчивый вариант - Шайи, но встречался мне и вариант Челли. Может лучше и проще Понькина латиницей?

---

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

Цитата:

---

Подразумевались все-таки возможности Access. Но в простейшем случае можно вообще обойтись Excel'ем.

---

Ага... Или текстовым файлом 8)

Цитата:

---

Для продвинутых - SQL Server.

---

Ну-ну :) Моя коллекция записей, кстати в SQL Server-e и хранится... Не думаю, что этот вариант многих устроит :D

Привет.

Цитата:

---

Сообщение от Eugene

Вот это всё - большой вопрос... Я бы, например, сделал один справочник людей и один справочник специальностей (фортепиано/скрипка/композитор/звукоинженер и т.д.).

---

Не, так не получится. Да и не правильно это. Могу объяснить почему.

Цитата:

---

Сообщение от SN

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

---

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

Цитата:

---

Сообщение от SN

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

---

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

Цитата:

---

Сообщение от SN

Цитата:

---

Какой язык пользователь захочет использовать, такой и должен быть.

---

Это конечно. Но давайте смотреть реально - подавляющее большинство дисков зарубежного производства, а фамилии многих из исполнителей не имеют сложившегося русского написания. Будем придумывать кто во что горазд? Вон у Бориса в дирижерах (да простит мне отец-основатель это буквоедство :) ) читаем: Шаилли, Рикардо. Это имелся ввиду Riccardo Chailly. Вообще-то в этом случае есть устойчивый вариант - Шайи, но встречался мне и вариант Челли. Может лучше и проще Понькина латиницей?

---

Встречаются две транскрипции Рахманинова: «Rachmaninov» и «Rachmaninoff». Вот я держу диск Грамзаписи, где написано Рахманинов, и только по-русски. Пример немного неудачен, потому как в случае Грамзаписи будет и латинское написание. Но очень часто встречаются диски с чисто русскими текстами. Ладно, выбрал «Rachmaninov». Дальше я купил диск фирмы Telarc где почему-то пишут «Rachmaninoff». Что делать? Заносить не так как на обложке? Некомильфо…
Идем дальше… А что значит англоязычный справочник? Как я могу запретить юзеру набивать в справочник текст на русском? Да у меня и механизмов-то нет таких: клавиатура все стерпит… Единственный вариант – поставляется нередактируемый справочник с заранее набитыми композиторами, но на это мы пойти не можем. :-) Не, абсолютно все справочники набиваются вручную самим пользователем, и по мере заполнения БД, пополняются справочники.

Здесь есть подводные камни. Скажем, глупый юзер сначала купит русский диск с Рахманиновым, привяжет к русскоязычной записи, через полгода аглицкий диск, создаст пункт «Rachmaninov», и привяжет только к нему. Соответственно при поиске один из дисков будет не найден, если в запросе будет задан только один из Рахманиновых.
Но тут я бессилен. Я не вижу способа опознать, что "Рахманинов", "«Rachmaninoff» и «Rachmaninov» - одно лицо. Как видно из этого примера, даже запрет на русский язык не спасает.

В общем, я считаю, что в данном случае только сам юзер – кузнец своего счастья. Либо при занесении нового диска привязывает к трем записям из справочника, а при появлении в справочнике новой транскрипции фамилии, находит ранее купленные диски и допривязывает.
Либо ни за чем не следит, а в запрос ставит три пункта. Либо из трех возможных транскрипций выбирает для себя только одну, ею и пользуется.
Либо справочник персоналий делается иерархическим, т.е. с древовидной структурой, заводится запись в той транскрипции, которая юзеру наиболее близка, все прочие транскрипции заносятся как подпункты. Возможно, это наиболее гибкий и правильный способ ведения БД: хочешь - ищешь только «Rachmaninoff», хочешь «Rachmaninov», ищещь его. Хочешь и того и другое - выбираешь запись более высокого уровня.

Других вариантов не вижу. Если кто ни будь видит выход, подскажите.

Serg

М-да хорошо бы иметь подробную базу интегрированную в сеть
Боря, странно что у тебя в базе нет поля с гиперссылками

Цитата:

---

Сообщение от Serg

Не, так не получится. Да и не правильно это. Могу объяснить почему.

---

Объясните!

Цитата:

---

Сообщение от Serg

Встречаются две транскрипции Рахманинова: «Rachmaninov» и «Rachmaninoff». Вот я держу диск Грамзаписи, где написано Рахманинов, и только по-русски. Пример немного неудачен, потому как в случае Грамзаписи будет и латинское написание. Но очень часто встречаются диски с чисто русскими текстами. Ладно, выбрал «Rachmaninov». Дальше я купил диск фирмы Telarc где почему-то пишут «Rachmaninoff». Что делать? Заносить не так как на обложке?

---

Надо сделать отдельно таблицу людей и отдельно - таблицу их имён :P

Цитата:

---

Сообщение от Eugene

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

---

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

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

Вот что значит - с умными людьми поговорить! И разобрались! :lol:

Теперь остается только сделать... :P
(Но с таблицами такими придется помучиться, со списками было бы легче... мне каается)

Цитата:

---

Сообщение от Genn

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

---

Вероятно, к этой базе моей надо делать help, но мне просто некогда этим заниматься. В моей базе одно произведение нумеруется (там есть поле "код"). Формат такой: LL-GGGG/NN где LL - тип носителя (напр., CD - компакты, TP - кассеты, VN - пластинки и т.п.), GGGG - номер носителя (предполагается, что все диски пронумерованы и выставлены один за другим), NN - номер пьесы на диске. Таким образом мы получаем однозначный идентификатор для любой пьесы. Иначе говоря, значимое поле только одно - этот самый код, ко все остальные можно вообще ничего не вводить (иногда бывает, не знаешь опуса или еще чего-то).

Цитата:

---

Сообщение от Serg

Цитата:

---

Сообщение от boris

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

---

Борис, Вы - музыкант или программист? :-) Вы очень точно понимаете основную проблему программистики: грамотная постановка задачи – 50% решения этой задачи. :-)

---

Я - то, что надо! :lol:

Цитата:

---

Сообщение от Serg

С другой стороны, всегда существовало такое понятие как Бета-тестирование :-) (В данном случае, речь не идет о бета-версии, падающей каждые полчаса. Речь идет о программной оболочке, работающей уже многие годы.) Опять таки, есть такое понятие как авторские экземпляры… Помощники в постановке - так же соавторы… :-)

---

Вот я как раз в этом направлении и думал.

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

Цитата:

---

Сообщение от Serg

Самый темный вопрос для меня на сегодняшний день. У меня есть понятие «единица хранения» и есть «единица поиска». Единица поиска немного крупнее, чем хранения. Т.е. если как сказал Genn единицей хранения должен быть опус (я с ним согласен в этом), и мы несколько опусов объединяем в «носитель», то единицей поиска будет «носитель».

---

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

Цитата:

---

Сообщение от SN

исполнителей не имеют сложившегося русского написания. Будем придумывать кто во что горазд? Вон у Бориса в дирижерах (да простит мне отец-основатель это буквоедство :) ) читаем: Шаилли, Рикардо. Это имелся ввиду Riccardo Chailly. Вообще-то в этом случае есть устойчивый вариант - Шайи, но встречался мне и вариант Челли. Может лучше и проще Понькина латиницей?

---

Вот спасибо! Исправлю завтра. :solution:
При всем при том мне кажется, что большой беды тут нет. Во-первых, эта база в принципе не делалась для того, чтобы кто-то еще, кроме меня, реально ею пользовался. Т.е. я не против, но это факультатив. Реально она делалась для того, чтобы я сам в ней мог найти максимально быстро то, что мне надо. Проще, конечно, было бы писать русских - русскими, а остальных - остальными, но там у меня встала проблема всяких тильд, и я решил, что пусть все будут на русском. Если кто-то решит, чтобы все по-английски - тоже вариант. В любом случае, мне кажется, последняя задача, которая ставится - это сделать базу совместным ресурсом. Насколько я вижу, каждый себе хочет домой такую штуку - ну так и пусть она дома будет у каждого своя. Нерасшаренная, пардон. 8)
Совместный ресурс - это, мне кажется, уже совсем другая песня. А в личной базе каждый может делать, как хочет, и искусственно ограничивать язык ввода, мне кажется, неразумно.

Цитата:

---

Сообщение от slava

Боря, странно что у тебя в базе нет поля с гиперссылками

---

Да я как-то не видел в этом необходимости. И сейчас не вижу. Я же дома ищу, а не в Сети. :)

Привет!

Цитата:

---

Сообщение от boris

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

---

То, что Вы называете эмоциями, в библиотечном деле называется «тематический указатель». :-) Переводя на более привычные нам компьтерные рельсы – никому в голову не придет хранить все свои файлы в корневой директории (кстати, такие вещи изредка случаются :-)) А вот как Вы организуете свой каталог – Ваша проблема. У кого-то это может быть симфоническая музыка, скрипичная музыка etc. Кто-то может разбить по времени – средневековая музыка, возрожденье… У кого-то будет – тяжеляк, трэш, амбиенс, арт-рок… :-)
Кроме того, база будет позволять хранить также критические статьи, обзоры… А почему нет? Их так же надо по папочкам раскладывать.

В общем, не вижу ничего плохого в том, что бы иметь тематический классификатор.

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

Цитата:

---

Сообщение от boris

Цитата:

---

Сообщение от Serg

Самый темный вопрос для меня на сегодняшний день. У меня есть понятие «единица хранения» и есть «единица поиска». Единица поиска немного крупнее, чем хранения. Т.е. если как сказал Genn единицей хранения должен быть опус (я с ним согласен в этом), и мы несколько опусов объединяем в «носитель», то единицей поиска будет «носитель».

---

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

---

Эт затем, что ФИЗИЧЕСКОЙ единицей хранения является конкретный экземпляр носителя, и конечной задачей является найти его на полке. :)

Кроме того, есть атрибуты общие для всех опусов на носителе: лейбл, его каталожный номер, год выпуска, место на Вашей полке… Представьте себе, что на диске 20 опусов. Представили? Для каждого задавать общие параметры?
То что я предлагаю, выглядит следующим образом: вы заносите документ – атрибутируете его. Затем заносите поддокументы. Для них Вы, вообще, можете не задавать никаких атрибутов – они автоматически наследуют общие атрибуты. Можете изменить некоторые атрибуты – они будут действительны только для данного поддокумента, скажем, номер опуса. Если при при поиске Вы зададите этот номер, то будут найдены все диски, содержащие этот опус.

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

Цитата:

---

Сообщение от boris

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

---

Опять таки, могу повторить, что база Ваша… Здесь мне только надо решить одно: делать справочники персоналий иерархическими, ну, т.е. дать Вам возможность в папке «Рахманинов» сделать подпапку «Rachmaninoff», или списочными.
Так что, прошу ответить на этот вопрос.

Цитата:

---

Сообщение от boris

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

---

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

Цитата:

---

Сообщение от boris

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

---

Эта песня когда ни будь будет спета, т.к. такая задача стоит, но о сроках я боюсь даже заикаться.

Цитата:

---

Сообщение от boris

Цитата:

---

Сообщение от slava

Боря, странно что у тебя в базе нет поля с гиперссылками

---

Да я как-то не видел в этом необходимости. И сейчас не вижу. Я же дома ищу, а не в Сети. :)

---

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

Serg

В выходные я решил немножко подробнее проанализировать задачу и попытаться сделать ее решение на Аксесе. У меня получилась система из следующих таблиц:
-record - информация о записи на каком-либо носителе.
- track - подчиненная Record таблица с информацией о треках. Трек - это может быть дорожка, а может быть и целиком сторона пластинки.
- opus - информация об опусах композитора
- person - все люди - композиторы, исполнители, дирижеры и т.д. (мне было лень делать две (а в потенциале и три ссылки на C.Рахманинова).
- orchestra - всякие оркестры, консорты и хоры (!)
- instrument - всяческие инструменты.

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

Проблема языков и ссылок решена следующим образом - все ключи видимы, они имеют тип Text 20, и предназначены для записи осмысленной абревиатуры, например BACH_JS. Благодаря такой абревиатуре - не имеет большого смысла, как именно дальше в поле Full Name будет поименован композитор. В принципе оно и так понятно, а остальное дело запросов.

Вот собственно и все. Благодаря такой реализации все базы допускают работу без дополнительной обвески в виде форм и ...
Но дальнейшая реализация уперлась в незнание Access. По привычке программирования на C/SIDE, я не смог в запрос передать значение из соседней ячейки редактируемой строки таблицы и на этом спотыкнулся. Такая передача значения мне необходима для того, чтобы список значений, выводимых в раскрывающееся поле был ограничен (список опусов ограничен композитором, который уже введен в строчку Track до того). Если кто знает как это сделать - подскажите. Собственно иные формы совместного творчества приветсвуются.

Цитата:

---

Сообщение от Genn

Проблема языков и ссылок решена следующим образом - все ключи видимы, они имеют тип Text 20, и предназначены для записи осмысленной абревиатуры, например BACH_JS. Благодаря такой абревиатуре - не имеет большого смысла, как именно дальше в поле Full Name будет поименован композитор. В принципе оно и так понятно, а остальное дело запросов.

Вот собственно и все. Благодаря такой реализации все базы допускают работу без дополнительной обвески в виде форм и ...
Но дальнейшая реализация уперлась в незнание Access. По привычке программирования на C/SIDE, я не смог в запрос передать значение из соседней ячейки редактируемой строки таблицы и на этом спотыкнулся. Такая передача значения мне необходима для того, чтобы список значений, выводимых в раскрывающееся поле был ограничен (список опусов ограничен композитором, который уже введен в строчку Track до того). Если кто знает как это сделать - подскажите. Собственно иные формы совместного творчества приветсвуются.

---

а ты кинь на сайт и дай ссылку посмотрть

последний абзац непонятен - ...
а ты пишешь не в самом аксессе?

Цитата:

---

Сообщение от slava

Цитата:

---

Сообщение от Genn

Вот собственно и все. Благодаря такой реализации все базы допускают работу без дополнительной обвески в виде форм и ...
Но дальнейшая реализация уперлась в незнание Access. По привычке программирования на C/SIDE, я не смог в запрос передать значение из соседней ячейки редактируемой строки таблицы и на этом спотыкнулся. Такая передача значения мне необходима для того, чтобы список значений, выводимых в раскрывающееся поле был ограничен (список опусов ограничен композитором, который уже введен в строчку Track до того). Если кто знает как это сделать - подскажите. Собственно иные формы совместного творчества приветсвуются.

---

а ты кинь на сайт и дай ссылку посмотрть

последний абзац непонятен - ...
а ты пишешь не в самом аксессе?

---

Своего сайта нет. Куда и как кидать - не знаю. :cry: Свой сайт для таких целей регистрировать - некогда. Да и не зачем пока.

Вообще с Аксессом не работал с 96 года. За это время он сильно изменился. Попробовал написать на нем решение без разборов с Бейсиком. Спасибо SNу - подсказал (напомнил), что значение для отбора можно передать из поля формы. Промучился несколько вечеров, пока допер, что некоторые слова внутри русского Аксесса нужно перевести на английский - тогда заработало.

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

Короче - вернулся на свой любимый C/Side (язык для NAVISION) и там все получилось гораздо быстрее. Но встала проблема переносимости - если кому-то ставить Navision - то нужно чтобы эта база работала из-под гостевой лицензии.

В общем - пока не приперло - как припрет (или время будет больше) - доделаю и расскажу.

А что если вернуться к исходной постановке задачи?
Вы хотите сделать систему для национального архива звукозаписи или для личной коллекции? Сколько дисков или записей в Вашем собрании?
Сколько записей Вы ожидаете получить на запрос по фамилии исполнителя (Сидоров) ?
Если в ответе на запрос по фамилии есть дата записи и роль (баян, скрипка, дирижер...), возникнут ли трудности найти нужную среди отобранных?
Вы хотите только ориентироваться в своей коллекции и находить все записи с исполнителем Сидоровым или уметь отдельно искать Sidorov и Sidoroff (зачем?)?
Вы всерьез собираетесь долбить аннотации и искать потом по их русскому тексту с учетом флексий? Так много дисков или проблемы с памятью?
Перечитайте постинги Boris'а, прислушайтесь к его разумным советам и вернитесь на землю.
У меня в собрании около 800 дисков. База на Access'е. Все сделано даже без макросов VB: 3 формы, 4 связанные таблицы, 3-5 отчетов. Знаю, как для себя решил бы все поставленные в потоке реальные задачи (кроме надуманных от избытка энтузиазма). И никаких проблем.
Профессиональное программирование - это еще и искусство упрощать. Книга Брукса вышла первым изданием лет 25 назад и, видимо, до сих пор не устарела.

Приветствую!

Цитата:

---

Сообщение от Посторонний

А что если вернуться к исходной постановке задачи?
Вы хотите сделать систему для национального архива звукозаписи или для личной коллекции? Сколько дисков или записей в Вашем собрании?

---

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

Сколько записей? А черт его знает… Некоторые даже не слушал еще. Две полки в шкафу компактов, около метра винила, еще полка компакт-кассет, металлический сундучок бобин, еще есть некоторое количество VHS, у сестры есть метра три винила…

Цитата:

---

Сообщение от Посторонний

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

---

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

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

Цитата:

---

Сообщение от Посторонний

Профессиональное программирование - это еще и искусство упрощать. Книга Брукса вышла первым изданием лет 25 назад и, видимо, до сих пор не устарела.

---

Бывает простота, которая хуже воровства.
Вы, видимо, не совсем хорошо представляете разницу между проектом «сделанным под себя», и универсальным решением. Есть такое понятие «коробочный софт» - установил, и все заработало. Пока тут только Борис предложил «решение под себя», но Genn’у оно не понравилось, и он принялся делать свою базу… Больше что-то пока никто не торопится делиться своими наработками. Итак, бедным меломанам предлагается иметь установленный «Офис», знать что такое Аццесс, уметь обращаться с ним… Нет, если Вы владеете Аксессом, то какие проблемы? Делайте под себя…

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

Serg

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

Цитата:

---

Сколько записей? А черт его знает…

---

Но разве не понятно, что это вопрос принципиальный: функциональность базы с 1,000 записей может быть гораздо проще, чем для базы с 1,000,000 записей. Хотя бы потому, что количество релевантных записей по содержательному запросу будет в первом случае, как правило, обозримо невооруженным глазом. И отобрав всё про Сидорова, вы уже из отсортированного списка отделите записи 1968 г. от записей 1999 г., и "баян" от "скрипки".
Дальше:

Цитата:

---

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

---

Так я и спрашиваю: какова постановка задачи? Каталог личного собрания? Или энциклопедия? Или сводный каталог мирового фонда звукозаписей? Есть Пингвиновский ежегодник, есть Граммофоновский, есть другие. Зачем все валить в одну кучу?
Именно поэтому я советую сначала ответить для себя на вопросы, которые я здесь и выше задал, а потом решать, что действительно надо автоматизировать, а что при планируемых объемах базы можно оставить на вторичную идентификацию в ручном контуре. И, поверьте, это не лень и не воровство, а просто здоровый прагматизм.
Дальше:

Цитата:

---

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

---

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

Разницу между коробочным продуктом и проектом "под себя" я хорошо знаю, поскольку разрабатываю системы для неподготовленного пользователя уже тридцать лет.
А вот про RE- грамматики хотел бы послушать. Хорошо знаю, что такое ER-модель данных (entity-relation), и не для одной предметной области такие строил. Действительно, правильно начинать проектирование с построения модели данных, и аппарат ER-моделей для нашего (вашего) случая подошел бы очень хорошо.
А RE-грамматики... Видно, отстал.
Не обижайтесь. Но все-таки, если хотите сделать систему, сначала решите, что нужно.

Приветствую!

Цитата:

---

Сообщение от Посторонний

Молодежь, что вы так болезненно реагируете? Я ведь не пытаюсь вас обидеть или обвинить в некомпетентности.

---

Гы-гы-гы! Я, вообще-то, далеко не вьюноша. :-)

Цитата:

---

Сообщение от Посторонний

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

---

С этим невозможно не согласиться.

Цитата:

---

Сообщение от Посторонний

Но разве не понятно, что это вопрос принципиальный: функциональность базы с 1,000 записей может быть гораздо проще, чем для базы с 1,000,000 записей. Хотя бы потому, что количество релевантных записей по содержательному запросу будет в первом случае, как правило, обозримо невооруженным глазом. И отобрав всё про Сидорова, вы уже из отсортированного списка отделите записи 1968 г. от записей 1999 г., и "баян" от "скрипки".

---

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

Нет, то что Вы хотите сказать, безусловно, понятно, но непонятно, почему Вы считаете, что я переутяжеляю задачу? Вы же не видели, что я имею, в качестве инструментария. Я еще раз повторяю: у меня есть этот инструмент. Он готов. И он значительно мощнее, по крайней мере, в смысле работы с текстовыми БД, нежели столь любимый здесь Аксесс.

Цитата:

---

Сообщение от Посторонний

Цитата:

---

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

---

Так я и спрашиваю: какова постановка задачи? Каталог личного собрания? Или энциклопедия? Или сводный каталог мирового фонда звукозаписей? Есть Пингвиновский ежегодник, есть Граммофоновский, есть другие. Зачем все валить в одну кучу?

---

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

Цитата:

---

Сообщение от Посторонний

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

---

Принято.

Цитата:

---

Сообщение от Посторонний

Так что "бедным меломанам" достаточно иметь Access и скопировать базу, а затем работать с готовыми интерфейсами.

---

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

Цитата:

---

Сообщение от Посторонний

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

---

Опа-на! Склоняю голову в глубоком пардоне! :-) Мой стаж в этой области значительно скромнее – всего 18 лет.

Цитата:

---

Сообщение от Посторонний

А вот про RE- грамматики хотел бы послушать. Хорошо знаю, что такое ER-модель данных (entity-relation), и не для одной предметной области такие строил.
<...>
А RE-грамматики... Видно, отстал.

---

Мы говорим об одном и том же. В книжке Озкарохана «Машины баз данных», помнится, это называлось грамматикой (давно не заглядывал в нее – уже лет 10. вечером уточню), а то, что буковки поменял местами… прошу пардону. :-)

Цитата:

---

Сообщение от Посторонний

Не обижайтесь. Но все-таки, если хотите сделать систему, сначала решите, что нужно.

---

Именно так. Если помните, то с этого я и начал разговор в начале топика.

Serg

Грамматики это здорово. В этом даже где-то что-то есть, «наверное». Но это уже начинается перекос в другую сторону. Я все же предпочитаю «здравый смысл» и простую схему данных в виде таблиц-квадратиков.
Коробочный продукт типа того, что описывает Serg (он же «вероятно» !KSL, он же …) здорово – но я боюсь сложного процесса ввода данных в него. Слава богу, составить запрос к кучке таблиц – для меня не очень большая проблема. Собственно говоря и запросы то простые. «Где у меня записан «Итальянский Концерт» - самый простой запрос. Более сложный – «А какие еще у меня есть записи, сочиненные в тот же период, когда был написан «Итальянский концерт»? А сколько было другим композиторам в тот период, когда был написан «Итальянский концерт»? Или – а сколько было ЖЛусье, когда он записывал вот эту версию Итальянского Концерта для Декки? И так далее.
Аксесс теоретически подходит для решения задачи – а практически …
Дальше – решение того, что нужно часто вырисовывается в процессе решения задачи. Сделать модель, повертеть ее на тестовых примерах и уточнить задачу и схему – достаточно просто.
И последнее замечание – мне нужно, чтобы решение обладало достаточно простым интерфейсом, упрощающим ввод данных – ввел один раз «Итальянский концерт», а потом «мышкуешь» его из перечня. Это несколько отличная от проблематики постановки запросов задача. Я бы даже сказал, что это - основная проблема ведения каталога записей любителем. Занести за один раз 200-300 новинок одним и тем же способом, это главная проблема.
И вот тут-та с интерфейсом ввода на засаду я и напоролся.

Приветствую!

Цитата:

---

Сообщение от Genn

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

---

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

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

Так что…

Цитата:

---

Сообщение от Genn

Коробочный продукт типа того, что описывает Serg (он же «вероятно» !KSL, он же …)

---

Ну что тебе Genn сказать? Можно поменять все что угодно, но стиль письма изменить, крайне, сложно. Да, я именно «та самая быдла, которая пишет свой ник с восклицательным знаком». Однако, ник я сменил не из-за злобного животного породы кошачьих. Так уж вышло, можно сказатьЮ случайно… сейчас жалею. Что касается второго «он же…», то тут я в некотором недоумении. Сколько себя помню, в инете у меня всегда был только ник !KSL. В юзнете другой – настоящая фамилия и имя. Опять же – исторически так сложилось, но ты ж вроде юзнет не читаешь?

Цитата:

---

Сообщение от Genn

здорово – но я боюсь сложного процесса ввода данных в него. Слава богу, составить запрос к кучке таблиц – для меня не очень большая проблема. Собственно говоря и запросы то простые. «Где у меня записан «Итальянский Концерт» - самый простой запрос. Более сложный – «А какие еще у меня есть записи, сочиненные в тот же период, когда был написан «Итальянский концерт»? А сколько было другим композиторам в тот период, когда был написан «Итальянский концерт»? Или – а сколько было ЖЛусье, когда он записывал вот эту версию Итальянского Концерта для Декки? И так далее.
Аксесс теоретически подходит для решения задачи – а практически …

---

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

Будем надеяться, что я эту БД таки добью (к сожалению, делаю факультативно по полчаса в неделю). После этого хотелось бы показать кому нибудь, что бы обсудить не «всухую»…

Цитата:

---

Сообщение от Genn

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

---

Так и должно быть.

Цитата:

---

Сообщение от Genn

И вот тут-та с интерфейсом ввода на засаду я и напоролся.

---

Отож! Юзерный интерфейс - самая большая проблема современной программистики.

Сергей К