Дайджест Дневника Обработки Пленок, Попытка систематизировать несистематизируемое :) |
Здравствуйте, гость ( Вход | Регистрация )
Дайджест Дневника Обработки Пленок, Попытка систематизировать несистематизируемое :) |
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, то у нас получится отношение между этими двумя таблицами "многие ко многим", соответственно, придется добавлять промежуточную таблицу для развязки этой ситуации. я конечно понимаю что нормализация и реляционные отношения спасут мир. но мы же не луноход проектируем? зачем такой сложный структура для такой простой задача? Структура, кстати, предельно простая... примитивная, я бы сказал. А нормализация значительно упростит задачу программисту. Всё выше мной написанное - это моя, как говорится, "бизатвецтвинная имха" В конечном итоге всё будет решать программист -------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
28.4.2011, 1:08
Сообщение
#4
|
|
Активный участник Группа: Пользователи Сообщений: 276 Регистрация: 23.9.2010 Пользователь №: 5896 |
б) Вы предлагаете убрать таблицу "Чувствительность", оставив при этом в таблице "Пленка" поле "Чувствительность" и реализовав непосредственно в коде программы выпадающий список возможных значений этого поля. Согласен, ряд чувствительностей стандартный. Но что мы будем делать, если завтра вдруг фирма 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 проработал. и проектировал и писал. практика показывает что нормализация "не до конца" а в некоторых случаях и введение некоторой избыточности (синхронизация которой ложится на тригеры) позволяет существенно упростить выборки и повысить быстродействие системы в целом. ибо несовершенен мир. и нельзя впихнуть невпихуемое -------------------- |
|
|
28.4.2011, 9:00
Сообщение
#5
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
вы мыслите как проектировщик, а я как программист )) Я стараюсь мыслить не как проектировщик, а как пользователь системы... ))) К слову сказать, кроме того, что я был в свое время главным проектировщиком, я был так же и ведущим программистом. Так-то я чистый сишник, но приложения БД разрабатывал на PL/SQL и MUMPS. Но мы же здесь, извините, не пиписьками собрались меряться, а проект реализовать удобный и функциональный для пользователя, в том числе и для нас с Вами! Так ведь? Так что предлагаю диспут завершить и приступать к реализации интерфейса. Когда будет готова альфа версия, примемся за её тестирование и поиск узких мест. По большому счету, так как не я программер в этом проекте, то мне не сильно важно, как Вы измените модель данных. Самое главное, чтоб система была функциональна и удобна для пользования. Рискну предположить, что всем потенциальным пользователям системы, которые за нами сейчас наблюдают, тоже не важно внутреннее устройство системы. Им важно удобство и функционал. если у нас просрочкой управляет одно поле (кол-во лет просрочки либо 0 если свежая) то выборки "не просроченная" "просроченная до 5 лет" просроченная свыше 5 лет" записываются проще и компактнее. Выборки для программера, согласен, проще и компактнее, а удобство для пользователя потерялось. А если, вдруг, встанет задача, найти все свежие пленки, у которых до истечения срока годности осталось не меньше года? Что делать-то будете? Заставите пользователя писать в это поле -1, -2, -3 и т.д.? Ну не та это система, чтоб начинать денормализовывать её для увеличения производительности. Не будет в ней сотен таблиц с миллионами записей! И сложных запросов тоже не будет! жаль, не поняли вы мою мысль. еще раз внимательно перечитайте то что я писал. Я понял Вашу мысль прекрасно! Вот только изначально в системе не ставилась задача, описать все растворы, присутствующие в процессе. Мы же не описываем, какую стоп-ванну или фиксаж использовали! Так почему мы должны описывать отбелки, осветлители и прочие жидкости? Мы определяем только пару пленка-проявитель. Если же мы решим, что необходимо будет описывать весь процесс, то модель надо расширять. Но пара провитель-раствор, на мой взгляд, всё равно останется. Нам просто придется замоделировать ситуацию, когда для каждой пары пленка-проявитель в каждой конкретной ИТЕРАЦИИ дальнейшая после проявления обработка различна! Вот и всё. это вы как проектировщик или как программист говорите? я с реляционками лет 10 проработал. и проектировал и писал. практика показывает что нормализация "не до конца" а в некоторых случаях и введение некоторой избыточности (синхронизация которой ложится на тригеры) позволяет существенно упростить выборки и повысить быстродействие системы в целом. ибо несовершенен мир. и нельзя впихнуть невпихуемое Полностью согласен с Вами в этом вопросе. Я очень часто в своей практике денормализовывал модель и вносил в неё избыточность, но ТОЛЬКО ПОСЛЕ ТОГО, как она была доведена до 3-ей НФ Вот только денормализация и избыточность вводятся тогда, когда они необходимы. В данном же случае я не считаю их применение целесообразным. Повторюсь, для меня главное - удобство и функционал системы. ЗЫ: я постарался этим своим сообщением максимально точно отразить свою позицию. В дальнейший диспут по поводу структуры бызы данных постараюсь не вступать. Всё отдаю на откуп программерам. И да пребудет с нами сила! -------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
Текстовая версия | Сейчас: 28.4.2024, 20:50 |