Дайджест Дневника Обработки Пленок, Попытка систематизировать несистематизируемое :) Опции

[3aBxo3]

...

[Relayer]

стоило отофлайнится немного а тут такое движение
народ! я конечно понимаю что нормализация и реляционные отношения спасут мир. но мы же не луноход проектируем? зачем такой сложный структура для такой простой задача?
ну вот смотрите:

1) чувствительность не надо выносить в отдельную табличку. ряд чувствительностей стандартный. в вебинтерфейсе выбор из списка

2) то же самое относится к разрешению скана. нефиг сканировать с разрешением 2741дпи народ этого не поймет

3) тип скана я бы вообще заменил на integer со значениями 0/1. ну и может быть 2 (правда не знаю что оно может означать)

4) сроки годности. я бы все же упростил и оставил одно integer поле - просрочка в годах. если оно 0 (по умолчанию) то материал не просроченный. дело в том что иногда приходится работать с материалом срок годности которого известен крайне неопределенно. но то что он просрочен скажем лет на надцать сказать можно с большой долей уверенности

5) таблицу "рецепт" я бы выбросил. "идентификатор пленки" добавить к "итерации". выбрать все итерации по цепочке проявитель-агитация-итерация не сложно - один запрос.

6) таблицы проявитель/раствор я бы объединил. всегда можно завести две записи - например Diafine A, Diafine B. я частенько использую в качестве второго раствора универсальные составы. т.е. первый раствор меняется а второй скажем такой же как и Diafine B.
в случае чб-слайд процесса либо кросспроцесса (обработки С41й пленки по чб) весь процесс многостадийный и там может участвовать несколько проявителей и других ванн (отбелка, осветление, чернение, фиксаж и тп). понятное дело что все эти ванны к проявителю имеют весьма далекое отношение, обычно являются универсальными и взаимозаменяемыми
в свете этого и расширения спектра процессов я бы объединил таблицы "проявитель" и "раствор". с полями: наименование, состав (текст) и тип раствора (проявитель, допроявляющий (для двухрастворников), стоп, отбелка, осветление, чернящий, фиксаж, вспомогательный и тп). при этом такие операции как замачивание, промывка и засветка тоже вписываются в эту схему! т.е. можно полностью расписать весь процесс (если он сложный скажем - у меня KodakVision2 по чб 8 ванн однако)
пункт спорный и обсуждаемый - так что надо думать

[3aBxo3]

Итак, давайте по-порядку!

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, то у нас получится отношение между этими двумя таблицами "многие ко многим", соответственно, придется добавлять промежуточную таблицу для развязки этой ситуации.

я конечно понимаю что нормализация и реляционные отношения спасут мир. но мы же не луноход проектируем? зачем такой сложный структура для такой простой задача?

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

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

[Relayer]

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

именно этот вариант я и предлагаю. сомневаюсь что фирма ильфорд выпустит пленку с чувствительностью 158ед ))
список стандартных чувствительностей забивается где-то массивом как константа. в идеале это отдельный маленький модуль с объявлениями глоб. констант

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

и часты вы их видели не стандартные? числовое поле. и константа массив (список дпи'шек)

Вот Вы сами как раз описали ситуацию, в которое одно поле типа integer мало чем поможет. Вы НЕ ЗНАЕТЕ, на сколько лет просрочена пленка, но точно уверены, что она просрочена. Какую цифру Вы проставите в этом поле? В описанной же мной модели в таблице "Годность пленки" всего два значения: свежая и просроченная, и Вы просто ставите у пленки признак, что она просрочена, а поле "Срок годности" оставляете пустым, ну или можете указать в нем приблизительный год истечения срока годности. Так что здесь я тоже категорически не согласен. Хотя тут не спорю, таблицу "Годность пленки" можно убрать и в таблицу "Итерация" просто добавить атрибут "Годность пленки", имеющий всего два значения.

вы мыслите как проектировщик, а я как программист )) если у нас просрочкой управляет одно поле (кол-во лет просрочки либо 0 если свежая) то выборки "не просроченная" "просроченная до 5 лет" просроченная свыше 5 лет" записываются проще и компактнее.

И как пользователь сможет выбирать все записи, относящиеся к проявителю Diafine? А так в таблице "Проявитель" будет запись "Diafine", а в таблице "Раствор" будет две записи "Diafine A" и "Diafine B", относящиеся к одной записи "Diafine".
Кстати, если, допустим, в таблице "Проявитель" добавить вторую запись типа "Diafine модифицированный (автор Relayer)" и к ней привязать имеющийся уже в таблице "Раствор" Diafine B, то у нас получится отношение между этими двумя таблицами "многие ко многим", соответственно, придется добавлять промежуточную таблицу для развязки этой ситуации.

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

процесс 1:
1) проявитель ORWO-567
2) отбелка двухромовокислая стандартная
3) осветление
4) тонирование в растворе с тиомочевиной

процесс 2:
1) проявитель ORWO-567
2) отбелка двухромовокислая стандартная
3) осветление
4) засветка
5) чернение в Kodak D-19

а никак. прийдется дублировать и делать такие записи:
1) чб-слайд ORWO-567 с тонированием тиомочевиной
2) чб-слайд ORWO-567 с засветкой и чернением в D-19

громоздко? не то слово

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

это вы как проектировщик или как программист говорите? я с реляционками лет 10 проработал. и проектировал и писал. практика показывает что нормализация "не до конца" а в некоторых случаях и введение некоторой избыточности (синхронизация которой ложится на тригеры) позволяет существенно упростить выборки и повысить быстродействие системы в целом. ибо несовершенен мир. и нельзя впихнуть невпихуемое