Дайджест Дневника Обработки Пленок, Попытка систематизировать несистематизируемое :) |
Здравствуйте, гость ( Вход | Регистрация )
Дайджест Дневника Обработки Пленок, Попытка систематизировать несистематизируемое :) |
28.4.2011, 1:08
Сообщение
#61
|
|
Активный участник Группа: Пользователи Сообщений: 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
Сообщение
#62
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
вы мыслите как проектировщик, а я как программист )) Я стараюсь мыслить не как проектировщик, а как пользователь системы... ))) К слову сказать, кроме того, что я был в свое время главным проектировщиком, я был так же и ведущим программистом. Так-то я чистый сишник, но приложения БД разрабатывал на PL/SQL и MUMPS. Но мы же здесь, извините, не пиписьками собрались меряться, а проект реализовать удобный и функциональный для пользователя, в том числе и для нас с Вами! Так ведь? Так что предлагаю диспут завершить и приступать к реализации интерфейса. Когда будет готова альфа версия, примемся за её тестирование и поиск узких мест. По большому счету, так как не я программер в этом проекте, то мне не сильно важно, как Вы измените модель данных. Самое главное, чтоб система была функциональна и удобна для пользования. Рискну предположить, что всем потенциальным пользователям системы, которые за нами сейчас наблюдают, тоже не важно внутреннее устройство системы. Им важно удобство и функционал. если у нас просрочкой управляет одно поле (кол-во лет просрочки либо 0 если свежая) то выборки "не просроченная" "просроченная до 5 лет" просроченная свыше 5 лет" записываются проще и компактнее. Выборки для программера, согласен, проще и компактнее, а удобство для пользователя потерялось. А если, вдруг, встанет задача, найти все свежие пленки, у которых до истечения срока годности осталось не меньше года? Что делать-то будете? Заставите пользователя писать в это поле -1, -2, -3 и т.д.? Ну не та это система, чтоб начинать денормализовывать её для увеличения производительности. Не будет в ней сотен таблиц с миллионами записей! И сложных запросов тоже не будет! жаль, не поняли вы мою мысль. еще раз внимательно перечитайте то что я писал. Я понял Вашу мысль прекрасно! Вот только изначально в системе не ставилась задача, описать все растворы, присутствующие в процессе. Мы же не описываем, какую стоп-ванну или фиксаж использовали! Так почему мы должны описывать отбелки, осветлители и прочие жидкости? Мы определяем только пару пленка-проявитель. Если же мы решим, что необходимо будет описывать весь процесс, то модель надо расширять. Но пара провитель-раствор, на мой взгляд, всё равно останется. Нам просто придется замоделировать ситуацию, когда для каждой пары пленка-проявитель в каждой конкретной ИТЕРАЦИИ дальнейшая после проявления обработка различна! Вот и всё. это вы как проектировщик или как программист говорите? я с реляционками лет 10 проработал. и проектировал и писал. практика показывает что нормализация "не до конца" а в некоторых случаях и введение некоторой избыточности (синхронизация которой ложится на тригеры) позволяет существенно упростить выборки и повысить быстродействие системы в целом. ибо несовершенен мир. и нельзя впихнуть невпихуемое Полностью согласен с Вами в этом вопросе. Я очень часто в своей практике денормализовывал модель и вносил в неё избыточность, но ТОЛЬКО ПОСЛЕ ТОГО, как она была доведена до 3-ей НФ Вот только денормализация и избыточность вводятся тогда, когда они необходимы. В данном же случае я не считаю их применение целесообразным. Повторюсь, для меня главное - удобство и функционал системы. ЗЫ: я постарался этим своим сообщением максимально точно отразить свою позицию. В дальнейший диспут по поводу структуры бызы данных постараюсь не вступать. Всё отдаю на откуп программерам. И да пребудет с нами сила! -------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
1.5.2011, 21:18
Сообщение
#63
|
|
аффтар Группа: Главные администраторы Сообщений: 4733 Регистрация: 22.12.2005 Из: Нижний Новгород Пользователь №: 6 |
Да-ааа, упустил я тему ... Теперь за голову хватаюсь ,и даже не знаю, с чего начать.
Ладно, начну с того, что я СОВСЕМ не программист, а ПОЛЬЗОВАТЕЛЬ. С "этого бока" и буду подходить. Еще раз для начала попытаюсь описАть, что было. А было ОЧЕНЬ похоже на старую версию: http://www.digitaltruth.com/devchart.php?F...&mdc=Search Т.е., ищущим пользователем вводилась пленка и проявитель, или пленка и ВСЕ проявители, или проявитель и ВСЕ пленки и выводилась таблица результатов (можно даже было ввести "все пленки" и "все проявители" - через несколько минут выводились ВСЕ результаты ). В старых записях сохранились такие "все результаты", и общий вид таблицы:
Прикрепленные файлы
-------------------- Не экономьте фиксаж и плёнку - они дёшевы; экономьте время и бумагу - они дОроги!
|
|
|
2.5.2011, 6:10
Сообщение
#64
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
Алексей! Тему Вы не упустили. Всю функциональность, которая была реализована в старом массиве, текущая модель данных позволит реализовать с лихвой.
Предлагаю дождаться от уважаемого девелопера первой версии, протестировать её и дать свои предложения по дальнейшему улучшению. -------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
2.5.2011, 11:09
Сообщение
#65
|
|
Активный участник Группа: Пользователи Сообщений: 114 Регистрация: 17.11.2010 Пользователь №: 5990 |
Точно. Данная функциональность будет даже перекрыта, по крайней мере задуманная структура это позволяет и простора для творчества уйма.
Праздники немного выбили из колеи - то агрофитнес, то ремонт. Несмотря на всё, постараюсь первую, частично работоспособную версию выложить после майских праздников, сильно не затягивая. |
|
|
22.6.2011, 15:50
Сообщение
#66
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
Боюсь даже спрашивать...
Процесс-то хоть движется? Или уже заглох? Если заглох, то я хотя бы для себя снова свой файлик заполнять начну... а то остановился на пол пути, жду результата. -------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
22.6.2011, 16:18
Сообщение
#67
|
|
Активный участник Группа: Пользователи Сообщений: 114 Регистрация: 17.11.2010 Пользователь №: 5990 |
Движется. Трудностей особых нет.
Не расчитал время. Думал за пару выходных сделаю, а тут какие-то спрошные поездки начались. Уже 2 месяца на выходных дома не был. Прошу прощения. Надо бы окрыситься, да поднажать. |
|
|
22.6.2011, 21:24
Сообщение
#68
|
|
Активный участник Группа: Пользователи Сообщений: 94 Регистрация: 7.2.2011 Из: Сургут Пользователь №: 9217 |
Прощения просить не за что! Это же проект на добровольной основе!
Мне главное знать, что не заглох, вот и всё -------------------- Хорошо смеётся тот, кто смеётся над собой! ©
|
|
|
10.7.2012, 15:23
Сообщение
#69
|
|
Участник Группа: Пользователи Сообщений: 9 Регистрация: 16.12.2011 Из: Красногорск Пользователь №: 47010 |
Оживить бы темку)
Что-то слышно о проекте? |
|
|
10.7.2012, 16:48
Сообщение
#70
|
|
аффтар Группа: Главные администраторы Сообщений: 4733 Регистрация: 22.12.2005 Из: Нижний Новгород Пользователь №: 6 |
При переходе на новый "движок" предусмотрено восстановление "массива проявок".
-------------------- Не экономьте фиксаж и плёнку - они дёшевы; экономьте время и бумагу - они дОроги!
|
|
|
Текстовая версия | Сейчас: 26.4.2024, 6:35 |