Дайджест Дневника Обработки Пленок, Попытка систематизировать несистематизируемое :) |
Здравствуйте, гость ( Вход | Регистрация )
Дайджест Дневника Обработки Пленок, Попытка систематизировать несистематизируемое :) |
16.4.2011, 15:44
Сообщение
#1
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
...
-------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
26.4.2011, 22:13
Сообщение
#2
|
|
Активный участник Группа: Пользователи Сообщений: 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 ванн однако) пункт спорный и обсуждаемый - так что надо думать -------------------- |
|
|
27.4.2011, 11:09
Сообщение
#3
|
|
Активный участник Группа: Пользователи Сообщений: 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, то у нас получится отношение между этими двумя таблицами "многие ко многим", соответственно, придется добавлять промежуточную таблицу для развязки этой ситуации. я конечно понимаю что нормализация и реляционные отношения спасут мир. но мы же не луноход проектируем? зачем такой сложный структура для такой простой задача? Структура, кстати, предельно простая... примитивная, я бы сказал. А нормализация значительно упростит задачу программисту. Всё выше мной написанное - это моя, как говорится, "бизатвецтвинная имха" В конечном итоге всё будет решать программист -------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
Текстовая версия | Сейчас: 29.4.2024, 10:53 |