Дайджест Дневника Обработки Пленок, Попытка систематизировать несистематизируемое :) |
Здравствуйте, гость ( Вход | Регистрация )
Дайджест Дневника Обработки Пленок, Попытка систематизировать несистематизируемое :) |
26.4.2011, 16:29
Сообщение
#41
|
|
Активный участник Группа: Пользователи Сообщений: 114 Регистрация: 17.11.2010 Пользователь №: 5990 |
Двухрастворные проявители можно учесть двумя записями Рецепта в Итерации. Для однорастворных - второй Идентификатор рецепта - NULL.
Трехрастворные и т.п. - слайды и цветная проявка - не стоит этой возни со структурой, я думаю. |
|
|
26.4.2011, 16:30
Сообщение
#42
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
И еще один момент. Хотелось бы устаканить терминологию.
Я привык к трем терминам, определяющим справочные структуры: - классификатор - может состоять из нескольких таблиц, например, классификатор должностей и профессий; - справочник - одна таблица, но несколько информационных полей, например, справочник организаций; - словарь - таблица, содержащая всего одно информационное поле, представляющее из себя список возможных значений атрибута. -------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
26.4.2011, 16:47
Сообщение
#43
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
Двухрастворные проявители можно учесть двумя записями Рецепта в Итерации. Для однорастворных - второй Идентификатор рецепта - NULL. Трехрастворные и т.п. - слайды и цветная проявка - не стоит этой возни со структурой, я думаю. Нет. На мой взгляд стоит сделать промежуточную между проявителем и итерацией таблицу, в которую вынести поля "Разбавление", "Время", "Температура" и "Агитация". Для однорастворного проявителя в этой таблице будет одна запись для каждой итерации, для двухрастворного - две и так далее. -------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
26.4.2011, 17:04
Сообщение
#44
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
Вобщем, пока как-то так... только кольцевая связь мне не нравится... мозги на сегодня больше не варят. Завтра буду еще думать.
Картинка удалена. -------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
26.4.2011, 17:06
Сообщение
#45
|
|
Активный участник Группа: Пользователи Сообщений: 114 Регистрация: 17.11.2010 Пользователь №: 5990 |
С терминологией согласен. Постараюсь придерживаться.
Насчет промежуточной можно подумать. Если выносим Идентификатор пленки в Итерацию, то все встает на свои места. |
|
|
26.4.2011, 22:13
Сообщение
#46
|
|
Активный участник Группа: Пользователи Сообщений: 276 Регистрация: 23.9.2010 Пользователь №: 5896 |
стоило отофлайнится немного а тут такое движение
народ! я конечно понимаю что нормализация и реляционные отношения спасут мир. но мы же не луноход проектируем? зачем такой сложный структура для такой простой задача? ну вот смотрите: 1) чувствительность не надо выносить в отдельную табличку. ряд чувствительностей стандартный. в вебинтерфейсе выбор из списка 2) то же самое относится к разрешению скана. нефиг сканировать с разрешением 2741дпи народ этого не поймет 3) тип скана я бы вообще заменил на integer со значениями 0/1. ну и может быть 2 (правда не знаю что оно может означать) 4) сроки годности. я бы все же упростил и оставил одно integer поле - просрочка в годах. если оно 0 (по умолчанию) то материал не просроченный. дело в том что иногда приходится работать с материалом срок годности которого известен крайне неопределенно. но то что он просрочен скажем лет на надцать сказать можно с большой долей уверенности 5) таблицу "рецепт" я бы выбросил. "идентификатор пленки" добавить к "итерации". выбрать все итерации по цепочке проявитель-агитация-итерация не сложно - один запрос. 6) таблицы проявитель/раствор я бы объединил. всегда можно завести две записи - например Diafine A, Diafine B. я частенько использую в качестве второго раствора универсальные составы. т.е. первый раствор меняется а второй скажем такой же как и Diafine B. в случае чб-слайд процесса либо кросспроцесса (обработки С41й пленки по чб) весь процесс многостадийный и там может участвовать несколько проявителей и других ванн (отбелка, осветление, чернение, фиксаж и тп). понятное дело что все эти ванны к проявителю имеют весьма далекое отношение, обычно являются универсальными и взаимозаменяемыми в свете этого и расширения спектра процессов я бы объединил таблицы "проявитель" и "раствор". с полями: наименование, состав (текст) и тип раствора (проявитель, допроявляющий (для двухрастворников), стоп, отбелка, осветление, чернящий, фиксаж, вспомогательный и тп). при этом такие операции как замачивание, промывка и засветка тоже вписываются в эту схему! т.е. можно полностью расписать весь процесс (если он сложный скажем - у меня KodakVision2 по чб 8 ванн однако) пункт спорный и обсуждаемый - так что надо думать -------------------- |
|
|
26.4.2011, 23:20
Сообщение
#47
|
|
Активный участник Группа: Пользователи Сообщений: 114 Регистрация: 17.11.2010 Пользователь №: 5990 |
Не луноход, да. Подождем главного dba. Что он скажет на это?
Вообще сейчас структура очень условная пока. Не зря в обсуждении открытом - нужно выслушать всех желающих, чтобы заложить в систему больший потенциал. По пунктам 1,2,3 - поддерживаю полностью. 4 - аналогично. Об этом говорил и то же предлагал ранее. Остальное - надо на свежую голову. Завтра. |
|
|
26.4.2011, 23:28
Сообщение
#48
|
|
Активный участник Группа: Пользователи Сообщений: 276 Регистрация: 23.9.2010 Пользователь №: 5896 |
ну это нормальный процесс обсуждения. даже после того как структуру более менее устаканим надо будет на нее еще раз посмотреть под кривым углом с точки зрения удобства использования
-------------------- |
|
|
27.4.2011, 11:09
Сообщение
#49
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
Итак, давайте по-порядку!
1) чувствительность не надо выносить в отдельную табличку. ряд чувствительностей стандартный. в вебинтерфейсе выбор из списка Я, конечно, не совсем понял Ваше предложение, но рискну предположить, что варианта два: а) Вы предлагаете вообще убрать значение "номинальная чувствительность пленки" из модели. В этом случае у пользователя не будет возможности выбрать все пленки одинаковой чувствительности для выбора нужной пленки под конкретную задачу. б) Вы предлагаете убрать таблицу "Чувствительность", оставив при этом в таблице "Пленка" поле "Чувствительность" и реализовав непосредственно в коде программы выпадающий список возможных значений этого поля. Согласен, ряд чувствительностей стандартный. Но что мы будем делать, если завтра вдруг фирма Ilford выпустит пленку с нестандартной чувствительностью? Правильно! Нам придется обращаться к программисту, чтоб он изменил код программы. Это плохая практика, и я ВСЕГДА стараюсь избегать подобных решений. Вобщем, моё мнение - словарь "Чувствительность" необходимо оставить и реализовать в интерфейсе какой-либо редактор словарей или же просто дать пользователю самому добавить новое значение в словарь с последующей модерацией. 2) то же самое относится к разрешению скана. нефиг сканировать с разрешением 2741дпи народ этого не поймет Ответ абсолютно идентичен пункту 1. Я бы даже сказал, что он более категоричен, ибо разрешения сканирования не стандартны. 3) тип скана я бы вообще заменил на integer со значениями 0/1. ну и может быть 2 (правда не знаю что оно может означать) В словаре "Тип скана" всего два значения: негатив и бумага (позитив). Вполне возможно, что негатив стоит разбить на два, типа негативный негатив и позитивный негатив . Как этот словарь реализовать, цифрами или словами, это не принципиально. Просто если цифрами, то программисту придется слова прописывать в коде, привязывая их к цифрам. Так что по этому вопросу у меня нет принципиальной позиции. Пусть прораммист делает так, как ему удобнее. 4) сроки годности. я бы все же упростил и оставил одно integer поле - просрочка в годах. если оно 0 (по умолчанию) то материал не просроченный. дело в том что иногда приходится работать с материалом срок годности которого известен крайне неопределенно. но то что он просрочен скажем лет на надцать сказать можно с большой долей уверенности Вот Вы сами как раз описали ситуацию, в которое одно поле типа integer мало чем поможет. Вы НЕ ЗНАЕТЕ, на сколько лет просрочена пленка, но точно уверены, что она просрочена. Какую цифру Вы проставите в этом поле? В описанной же мной модели в таблице "Годность пленки" всего два значения: свежая и просроченная, и Вы просто ставите у пленки признак, что она просрочена, а поле "Срок годности" оставляете пустым, ну или можете указать в нем приблизительный год истечения срока годности. Так что здесь я тоже категорически не согласен. Хотя тут не спорю, таблицу "Годность пленки" можно убрать и в таблицу "Итерация" просто добавить атрибут "Годность пленки", имеющий всего два значения. 5) таблицу "рецепт" я бы выбросил. "идентификатор пленки" добавить к "итерации". выбрать все итерации по цепочке проявитель-агитация-итерация не сложно - один запрос. Тут буду думать ещё. Ответ для меня пока не очевиден. 6) таблицы проявитель/раствор я бы объединил. всегда можно завести две записи - например Diafine A, Diafine B. я частенько использую в качестве второго раствора универсальные составы. т.е. первый раствор меняется а второй скажем такой же как и Diafine B. И как пользователь сможет выбирать все записи, относящиеся к проявителю Diafine? А так в таблице "Проявитель" будет запись "Diafine", а в таблице "Раствор" будет две записи "Diafine A" и "Diafine B", относящиеся к одной записи "Diafine". Кстати, если, допустим, в таблице "Проявитель" добавить вторую запись типа "Diafine модифицированный (автор Relayer)" и к ней привязать имеющийся уже в таблице "Раствор" Diafine B, то у нас получится отношение между этими двумя таблицами "многие ко многим", соответственно, придется добавлять промежуточную таблицу для развязки этой ситуации. я конечно понимаю что нормализация и реляционные отношения спасут мир. но мы же не луноход проектируем? зачем такой сложный структура для такой простой задача? Структура, кстати, предельно простая... примитивная, я бы сказал. А нормализация значительно упростит задачу программисту. Всё выше мной написанное - это моя, как говорится, "бизатвецтвинная имха" В конечном итоге всё будет решать программист -------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
27.4.2011, 11:30
Сообщение
#50
|
|
Активный участник Группа: Пользователи Сообщений: 114 Регистрация: 17.11.2010 Пользователь №: 5990 |
Вот. Немного подумал и получается что.
1. Чувствительность все таки надо связывать с Фирмой производителем. Есть стандартный ряд чувствительностей, но есть и стандартные пленки. Fomapan 100,200,400 но нет Fomapan 160. Так что это разумно. 2. Тип пленки нельзя привязывать к итерации. Он должен быть привязан к пленке. 3. Связка Рецепт-Проявитель-Раствор мне что-то не нравится. Может Проявитель и Раствор объединить, а между Рецептом и Проявителем сделать связующую таблицу один ко многим. Возможность описывать многорастворные проявители. И на перспективу. Надо придумать доменное имя для проекта. Идеи есть? Что-то с воображением совсем туго. Или третий уровень у d-76.ru выпросить? |
|
|
27.4.2011, 12:10
Сообщение
#51
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
1. Чувствительность все таки надо связывать с Фирмой производителем. Есть стандартный ряд чувствительностей, но есть и стандартные пленки. Fomapan 100,200,400 но нет Fomapan 160. Так что это разумно. Коллега! Я в корне не согласен! Атрибут "Чувствительность" характеризует только сущность "Пленка", но никак не сущность "Фирма производитель". 2. Тип пленки нельзя привязывать к итерации. Он должен быть привязан к пленке. Тоже не согласен. Тип пленки - это 135, 120, 110, листовая и т.д. Если его привязать к пленке, то у нас в таблице "Пленка" для каждой пленки, допустим Fuji 100 Acros, будет N-ное количество записей, а именно "Fuji 100 Acros 135", "Fuji 100 Acros 120", "Fuji 100 Acros 110", "Fuji 100 Acros листовая". Ну и что нам потом с этим делать? Гораздо легче выбрать из списка пленку, а потом все итерации категоризировать по типам пленки. 3. Связка Рецепт-Проявитель-Раствор мне что-то не нравится. Может Проявитель и Раствор объединить, а между Рецептом и Проявителем сделать связующую таблицу один ко многим. Возможность описывать многорастворные проявители. Многорастворные проявители описываются парой Проявитель-Раствор. Рецепт собирает воедино пару Пленка-Проявитель. Итерация позволяет один и тот же рецепт повторять многократно разным людям при разных условия. Вобщем, я сегодня обдумал модель на свежую голову. На мой взгляд, модель целостна, напротиворечива, нормализована и близка к завершенному состоянию. Теперь бы хотелось узнать кандидатуру программера всего этого безобразия, хотелось бы, чтоб он начал кодить и решать с ним вопросы, возникающие у него в процессе кодирования. И на перспективу. Надо придумать доменное имя для проекта. Идеи есть? Что-то с воображением совсем туго. Или третий уровень у d-76.ru выпросить? Тут большой простор для фантазии всего сообщества -------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
27.4.2011, 12:32
Сообщение
#52
|
|
Активный участник Группа: Пользователи Сообщений: 114 Регистрация: 17.11.2010 Пользователь №: 5990 |
Коллега! Я в корне не согласен! Атрибут "Чувствительность" характеризует только сущность "Пленка", но никак не сущность "Фирма производитель". Тоже не согласен. Подобная организация БД позволяет иметь мусор. Давайте решим, валидацией данных либо БД занимается, либо админ. Тоже не согласен. Тип пленки - это 135, 120, 110, листовая и т.д. Если его привязать к пленке, то у нас в таблице "Пленка" для каждой пленки, допустим Fuji 100 Acros, будет N-ное количество записей, а именно "Fuji 100 Acros 135", "Fuji 100 Acros 120", "Fuji 100 Acros 110", "Fuji 100 Acros листовая". Ну и что нам потом с этим делать? Гораздо легче выбрать из списка пленку, а потом все итерации категоризировать по типам пленки. На мой взгляд все логично. Есть типы пленки 135, 120, листовая и т.п. У каждого типа есть Фирма производитель - Ilford, Foma, Fuji... У каждой Фирмы производителя есть наименования пленки у Ilford'а Delta, HP, FP. У фомы - classic и еще чего-то там и т.п. У наименования могут быть разные чувствительности Нормальное такое дерево зависимостей. Многорастворные проявители описываются парой Проявитель-Раствор. Рецепт собирает воедино пару Пленка-Проявитель. Итерация позволяет один и тот же рецепт повторять многократно разным людям при разных условия. Вобщем, я сегодня обдумал модель на свежую голову. На мой взгляд, модель целостна, напротиворечива, нормализована и близка к завершенному состоянию. Ну в остальном пусть будет так. Тестирование покажет. Теперь бы хотелось узнать кандидатуру программера всего этого безобразия, хотелось бы, чтоб он начал кодить и решать с ним вопросы, возникающие у него в процессе кодирования. Я? Если доверяете это дело, то возьмусь. Только выбор ЯП за мной - это Perl. Тут большой простор для фантазии всего сообщества Где фантазии? Предлагайте! devfilm.ru chartfilm.ru |
|
|
27.4.2011, 12:51
Сообщение
#53
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
Тоже не согласен. Подобная организация БД позволяет иметь мусор. Вот если честно, то я Вас в этом месте не понял. Ну да ладно. Я? Если доверяете это дело, то возьмусь. Только выбор ЯП за мной - это Perl. Лично я доверяю. Дальнейший спор по поводу модели данных считаю бессмысленной тратой времени. Процесс кодирования расставит все точки над "и". Ну а так как кодер Вы, то Вам и карты в руки. Хотелось бы только услышать мнение Алексея. У него были какие-то идеи, под которые, по всей видимости, модель надо будет доработать. Где фантазии? Предлагайте! devfilm.ru chartfilm.ru Пока приличных идей нет. Если появятся, то отпишусь. -------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
27.4.2011, 12:57
Сообщение
#54
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
Кстати, домен devchart.ru вроде свободен.
-------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
27.4.2011, 13:05
Сообщение
#55
|
|
Активный участник Группа: Пользователи Сообщений: 114 Регистрация: 17.11.2010 Пользователь №: 5990 |
Да, подождем Алексея. Была же какая-то идея с температурными зависимостями, только я не совсем понял. Все таки человек гораздо более опытный в этом плане, чем я. Выслушать надо.
Кстати, домен devchart.ru вроде свободен. Нет, не свободен. $ whois devchart.ru % By submitting a query to RIPN's Whois Service % you agree to abide by the following terms of use: % http://www.ripn.net/about/servpol.html#3.2 (in Russian) % http://www.ripn.net/about/en/servpol.html#3.2 (in English). domain: DEVCHART.RU nserver: parking1.nic.ru. nserver: parking2.nic.ru. state: REGISTERED, DELEGATED, VERIFIED person: Private Person e-mail: molaruso@gmail.com registrar: REGISTRATOR-REG-RIPN created: 2010.04.06 paid-till: 2012.04.06 source: TCI Last updated on 2011.04.27 13:58:42 MSK/MSD devchart.net, devchart.su, devchart.org - свободны и еще третьего уровня можно. |
|
|
27.4.2011, 13:36
Сообщение
#56
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
Домен devchart хорош, на мой взгляд, тем, что он уже на слуху и многие, наверняка, задают это слово в поисковиках. Я и сам однажды искал это слово
-------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
27.4.2011, 13:51
Сообщение
#57
|
|
Активный участник Группа: Пользователи Сообщений: 114 Регистрация: 17.11.2010 Пользователь №: 5990 |
Да, devchart хорош.
Как это всё заработает, неплохо было договориться с админами фотоаптеки, чтобы разместить линки на наш массив и с массива на фотоаптеку. А я потихоньку начинаю реализацию. По мере наличия свободного времени. Пока с рюшечками в интерфейсе заморачиваться не буду - упор на функционал. Раскрашивать потом будем. |
|
|
27.4.2011, 14:12
Сообщение
#58
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
Кстати, домен devchart.ru зарегистрировал на себя автор сайта darkroom.ru, он же molaruso, он же Виталий Кузьмин
-------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
27.4.2011, 19:23
Сообщение
#59
|
|
Активный участник Группа: Пользователи Сообщений: 54 Регистрация: 3.9.2010 Пользователь №: 5874 |
Кстати, домен devchart.ru зарегистрировал на себя автор сайта darkroom.ru, он же molaruso, он же Виталий Кузьмин Так может этот Виталий Кузмин в благородных целях уступит столь звучный и нужный ему просто про запас домен на благое бескорыстное дело? кто то знаком с этим человеком? Наблюдаю за этой веткой и тихо соплю в уголочке от удовольствия и гордости за вас ребята. я во все этом мало понимаю, но как активный потребитель того, что вы задумали, молюсь и благословляю вас Думаю, что вы заткнете за пояс digitaltruth.com и заставите всех учить Русский язык |
|
|
27.4.2011, 21:02
Сообщение
#60
|
|
Активный участник Группа: Пользователи Сообщений: 114 Регистрация: 17.11.2010 Пользователь №: 5990 |
Так может этот Виталий Кузмин в благородных целях уступит столь звучный и нужный ему просто про запас домен на благое бескорыстное дело? кто то знаком с этим человеком? Может таки кто обладает дипломатическим талантом, проведет переговоры? Контакты на сайте есть. Если уж нет, то зареглю devchart.net Наблюдаю за этой веткой и тихо соплю в уголочке от удовольствия и гордости за вас ребята. я во все этом мало понимаю, но как активный потребитель того, что вы задумали, молюсь и благословляю вас Думаю, что вы заткнете за пояс digitaltruth.com и заставите всех учить Русский язык Таки у Вас будет возможность поучаствовать в развитии проекта, если есть желание. Наполнять информацией, причесывать, следить за порядком ещё потребуются добровольцы Но это чуть позже. Пока я воюю с MySql. После оракла это нечто. Но куда оно денется |
|
|
Текстовая версия | Сейчас: 29.4.2024, 0:02 |