Версия для печати темы

Автор: 3aBxo3 16.4.2011, 15:44

...

Автор: artoptics 19.4.2011, 8:44

нафига ...

Автор: 3aBxo3 19.4.2011, 11:14

...

Автор: dimich 19.4.2011, 11:20

Задумка конечно хорошая, но что такое Microsoft Office OneNote 2010 не знаю. Поэтому использовать не буду.
Если что-то хотите систематизировать, может лучше веб-страничку нарисовать, сделать удобную сортировку, поиск? С возможностью обновления участниками форума? Могу даже у себя захостить. 24/7 гарантированно. Можно и с админами переговорить, может они разрешат к форуму прикрутить? Хотя врядли они на это пойдут. Массив и тот чинить никто не хочет.

Автор: 3aBxo3 19.4.2011, 11:34

Спасибо! Я понял, что подобная фигня никому не интересна, поэтому принято решение более не напрягаться и не выкладывать её в инете.
Тему можно снести.

Автор: dimich 19.4.2011, 12:42

Не, ну так уж радикально - зря Вы. Зачем по двум человекам судите по остальным. Вероятно кто-то уже скачал и сказал про себя "спасибо".
Я же всего-навсего предложил несколько другую схему ведения дневника. В его наполнении могут участвовать все, а контролировать процесс - ответственные за это дело. Например - Вы.
Верните пост и ссылку на место. И не судите строго. Мое мнение - это не мнение всех остальных. Извините, если обидел.

З.Ы. Если интересно - могу технически реализовать свою задумку - более расширенную версию девчарта с блекджеком и ш красивыми описаниями, картинками-примерами и комментами, поиском. Поможете?

Автор: 3aBxo3 19.4.2011, 16:50

Не обидели. Я просто осознал, что оно действительно никому не нужно.



Хм. А какого рода помощь Вам требуется?

Автор: dimich 19.4.2011, 19:57

Чушь. Нужно!

Можно вместе систематизировать и создать упорядоченный справочник. Была сперва мысль написать движок справочника и наполнить его информацией. Но сама по себе информация не очень интересна. Интересно ее обновление, возможность ее добавления и корректировки силами сообщества. При трезвом взгляде, на эту роль хорошо подходит движок wiki или тот же форум. Где отдельная тема - описание какой либо пленки в каком нибудь проявителе или как то так. Можно конечно и изобрести велосипед, написав с нуля - не против.

Вот помощь нужна собственно в развитии идеи, помощь в классификации существующего, помощь в развитии творения, модерировании и т.п.

Так что для начала верните наработки на место. Считайте мою неудавшуюся критику похвалой. Я - за. Благое дело вы задумали.

Автор: Relayer 20.4.2011, 20:45

эх ... усе пропустил граждане - в чем суть идеи? и де то что выложили ... и снесли?
продвинутый девчарт может быть интересен. но только с примерами картинок и кропами. иначе это неинформативно получается. для себя последнее время завел хорошую практику - все новые растворы на одной и той же сцене сравниваются с чем-то эталонным. обычно это либо д76, либо д76д с резкостной допроявкой. и все как на ладони - и зерно и резкость и тональность и прочие тонкости

Автор: Aleksiy 20.4.2011, 21:07

Простите, что не ответил сразу.
Разумеется, это делать НАДО!!!

И лично я это всемерно приветствую.

В свое время (в "Текущем дневнике проявок...", в начале этот процесс отслежен) за основу был взят:
http://www.digitaltruth.com/devchart.php?Film=&Developer=&mdc=Search
- он был русифицирован, к нему были добавлены практические результаты нескольких людей а потом введена "встроенная" температурная коррекция (по 7% времени на каждый 1С - простейший вариант). Далее это было "прикручено" к Форуму и сделана заполняемая форма введения новых результатов. Вводимые результаты просматривались модератором и активизировались. Долгое время все работало замечательно, а вот потом полезли спаммеры (боты) . До нескольких СОТЕН постов в эту форму ежедневно! Внесение новыз результатов совершенно "захлебнулось". А потом и модуль массива "подломали" - пришлось дезактивировать...

Восстановитьть что-либо подобное ОЧЕНЬ бы хотелось, но КАК все это будет в свете вышеприведенных проблем? Тут надо думать...

И еще, Павел с Ольгой сейчас физически переезжают в Москву, и судя по всему именно по этому не могут сейчас особенно отвечать в Форуме; а так я думаю, немало конструктивного уже сказали бы.

Автор: Relayer 21.4.2011, 0:50

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

Автор: 3aBxo3 21.4.2011, 5:56

Ребята! Можно я сразу всем отвечу?

Моя имха, так сказать

1. Для того, чтобы реализовывать подобный проект, нужно много свободного времени. У кого его много?

2. У проекта должен быть только ОДИН идеолог (руководитель проекта). Когда у проекта несколько голов, ни к чему хорошему это не приводит. Поэтому для начала нужно выбрать человека, который будет держать бразды правления и собирать все мысли воедино. Главные требования - огромное желание реализовать подобный проект, знание и понимание предметной области и наличие свободного времени. Все остальные могут только генерировать идеи и выполнять чётко поставленные задачи руководителя проекта.


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

Автор: 3aBxo3 21.4.2011, 6:05

То, что было выложено, не является тем, что Вы хотели бы видеть
Это всего лишь собранные в электронной записной книжке (Microsoft OneNote 2010, ставится вместе с офисом) и систематизированные по пленкам рецепты из дневника обработки пленок.

Автор: Relayer 21.4.2011, 15:35

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

Автор: dimich 21.4.2011, 16:19

Прямо так сказать, что свободного времени много - значит соврать. Пару часов после работы, чуть больше в выходные могу выделить. Естественно всё не очень быстро получится. Это надо понимать.

Сперва совместно нужно выработать общую концепцию. Определить, что хотим получить на выходе. В open-source разработках принимают участие люди со всех точек планеты, но координатор должен быть один. В крайнем случае очень сплоченный коллектив, где все друг другу доверяют и понимают друг друга.

Да, конечно. Множество методов борьбы. Самый простой - капча или апрув админа.

Автор: 3aBxo3 21.4.2011, 17:19

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



Хорошо! Скажите мне, пожалуйста, как Вы представляете себе совместную выработку общей концепции?




Вот об этом я и говорю. Только использую для этого термин "руководитель проекта".

Автор: dimich 21.4.2011, 18:40

1. Выбрать руководителя проекта.
2. Выслушать мнение остальных по поводу функционала, дизайна, новых фич и т.п.
3. На основе сформировавшейся по п.2 картины построить для себя техзадание, утвердить его.
4. Определиться с разработчиком(ами) и приступить к реализации.
5. В процессе разработки предоставлять возможность тестирования всем желающим.

Как-то так наверное.

Автор: Relayer 22.4.2011, 1:26

3.1 вынести техзадание на публичное обсуждение.
3.2 внести последние корректировки по результатам п. 3.1

Автор: 3aBxo3 22.4.2011, 3:28

Хм! Странно! Процесс мы с Вами понимаем одинаково.
Получается, что говорим об одном и том же, но в разных местах расставляем акценты, поэтому не можем друг друга понять

Автор: dimich 22.4.2011, 9:09

С пунктами 3.x согласен.
Можно ли теперь, пока не выполнен пункт 1, начать обсуждение пункта 2?

Попробую выразить мысль, как я хочу видеть дневник:
1. Каждая запись в дневнике описывает какую-то одну обработку конкретной пленки в конкретном проявителе с конкретными режимами агитации.
2. Запись имеет следующие поля:
а) Вид пленки (фотоматериала) напр. FOMAPAN 100
б) Вид проявителя, напр. Rodinal
в) Разбавление проявителя, напр. 1+100
г) Другие изменения в рецептуру, напр. добавление бензотриазола 0.1
д) Температура проявления, напр. 20C
е) Условия агитации
ж) Сканы негативов
з) Сканы позитивов (отпечатков)
и) Описание процесса, личное мнение о результате и т.п.
к) Комментарии

3. При такой структуре хранения записей в БД можно просто получить дополнительные необходимые фичи:
А) Представление дневника в наглядной табличной форме
Б) Сортировка по а) пленке, б) проявителю
В) Наглядное сравнение двух и более проявок между собой

Вот. Сейчас подумаю, еще допишу. Чего-то хотелось еще....

Автор: 3aBxo3 22.4.2011, 10:53

Можно. Вот только пока нет человека, который будет всё это консолидировать и отделять зерна от плевел, всё это будет лежать мёртвым грузом или будет использовано сторонним разработчиком для реализации своего проекта. Да, согласен, я параноик



Только рекомендую не хранить данные в одной таблице, а всё-таки создать нормальную реляционную модель хранения данных. Я готов её спроектировать. Осталось только определиться с СУБД.
Отображение же данных пользователю в одно-табличном представлении возможно.

Автор: 3aBxo3 22.4.2011, 10:56

Также, на мой взгляд, будет полезной функция, которая позволит пользователям добавлять уже к существующим рецептам свой результат повторения этого рецепта со своими примерами сканов. Надеюсь, что понятно объяснил )))

Автор: dimich 22.4.2011, 11:14

Да, конечно дополнения разумные. Как-то я упустил их.
Что касается, СУБД, то разницы большой не вижу, если не отклоняться от стандартов. MySQL везде есть, думаю его и стоит использовать. Это облегчит перенос между площадками.
И конечно же реляционные возможности СУБД надо использовать. Фирмы-производители, виды пленок, проявителей и иже с ним напрашиваются само-собой в справочники.
Набросайте структуру табличек, если есть время - обсудим ее. (Мне сейчас немного некогда - срочная работа, я лучше как DBA поучаствую в обсуждении и корректировке структуры). Уверен, все сделаете правильно.

Автор: dimich 22.4.2011, 11:24

Что если ввести понятия как Основной результат и Повторение результата. Тогда Повторение результатов - это что-то вроже комментариев к Основному результату. Можно им отдельный статус дать. А вообще, комменты там не уместны видимо. Для этого форум есть. Добавление Повторения результата с примерами - пожалуйста. Если рецепт модифицирован, то это отдельный Основной результат.
Так? Не запутались?

Автор: Relayer 24.4.2011, 21:47

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

Автор: Relayer 25.4.2011, 18:40

еще один момент - просрочка. неплохо бы где-то делать отметку что пленка просрочена на столько-то лет с возможностью делать выборку "только просрочка"
PS это по свежим следам так сказать - сегодня проявлял широкую свему64 просрочка 93го года без бромистого. и без бензотриазола. вообще без каких-то антивуалентов. на выходе идеальные негативы - вуали просто нет. зерно в норме. фантастика блин

Автор: dimich 25.4.2011, 21:35

Да, ценные дополнения. Стоит прислушаться к вашему мнению. Итак, за отсутствием активности других участников, позволю себе сделать наброски структуры базы и завтра выложить. Надо начинать документировать это дело и приступать к реализации. Сегодня уж извините, устал и глаза слипаются Руководителя проекта так и не выбрали

Автор: Aleksiy 25.4.2011, 22:13

Еще мысли есть, но вот силенок сейчас имеется ровно на то, чтобы сказать об этом...
Завтра постараюсь довести.

Автор: 3aBxo3 26.4.2011, 3:39

Над структурой я уже работаю.
Руководителя нет, поэтому в команде разброд и шатание

Автор: dimich 26.4.2011, 7:37

Предлагаю на всеобщее голосование кандидатуру 3aBxo3, если он конечно согласен. Если согласен, то один голос (мой) уже есть. Думаю, хорошая кандидатура на должность руководителя.

Автор: dimich 26.4.2011, 7:57

Ваша помощь и участие, Aleksiy, очень требуется. Заранее спасибо!

Автор: 3aBxo3 26.4.2011, 8:32

У меня из требуемых качеств руководителя присутствует только одно - огромное желание реализовать проект. У меня крайне мало свободного времени и почти полное отсутствие знаний предметной области.

Я вот как раз Вашу кандидатуру хотел предложить. Активности Вам не занимать, знаний тоже. Площадка для реализации проекта Ваша. Рискну предположить, что у Вас серьезные навыки DBA и девелопера. С желанием реализовать проект, похоже, тоже всё в полном порядке

ЗЫ: это не алаверды! Это серьёзное предложение

Автор: 3aBxo3 26.4.2011, 8:37

Алексей! С днем рождения Вас! Здоровья и долгих лет жизни!


Если верить форумному напоминателю, то мы с Вами одногодки

Автор: dimich 26.4.2011, 10:04

Вот оно значит как! А я то проглядел
Алексей! Поздравляю от всей души! Пусть и оффтоп, но зато это искреннее желание поздравить и поблагодарить Вас! Будьте здоровы, пусть все будет у вас замечательно всегда и всегда Вы будете с нами. Вы хороший человек, я это знаю. Будьте всегда таким!!!

Автор: 3aBxo3 26.4.2011, 15:01

Итак, пока первая версия модели для предварительного обсуждения.
Завтра подумаю, как реализовать механизм описания двухрастворных проявителей.

Картинка удалена.

Автор: dimich 26.4.2011, 15:58

Ага, ну почти как я и представлял себе. На досуге осмыслю структуру и внесу еще предложения. Пока же есть пару непонятных моментов:
1. Годность пленки. Зачем это делать через справочник? Фактически годность пленки можно выразить целым числом INTEGER в годах просрочки. 0-в пределах срока годности, 1-1 год просрочки и т.д. Или что-то иное задумывалось, потому как в таблице "Итерация" есть "Срок годности пленки"?
2. "Тип скана" - скан негатива или отпечатка. Так понимаю?
3. Так же против справочника "Разбавление". Разбавления нестандартны, помимо ходовых 1+2, 1+3 разбавляют более оригинально, 1+50,1+60 - в общем простор для творчества. Предлагаю просто типизировать запись о разбавлении и не вводить справочник.

Ни в коем случае не критика, выяснение рабочих моментов - чего недопонял.

В остальном, структура очень адекватна. Можно взять за основу.

Upd. Да, и в таблице "Пользователь", пароли хранить не стоит. Хэш пароля - да.

Автор: 3aBxo3 26.4.2011, 16:13

Словарь "Годность пленки" сделан для легкого разделения пленок на просроченные и нет. В нем всего два значения: "Свежая" и "Просроченная". Человек ведь может и не знать срока годности пленки, но быть уверенным в том, что она реально просрочена. В этом случае он проставляет, что пленка просрочена и не ставит срок годности. Если же известен срок годности, то он ставится для того, чтобы тот, кто будет читать рецепт, сам мог вычислить срок просрочки. Кстати, для этого надо фиксировать дату рецепта или дату добавления рецепта в базу.



Именно так.



Особых возражений нет.



Таблица "Пользователь" пока в набросочном варианте. Я не имел ввиду, что в ней будет храниться пароль в открытом виде


ЗЫ: приятно побеседовать с человеком, который разбирается в построении реляционных моделей данных

Автор: 3aBxo3 26.4.2011, 16:22

Кстати, забыл добавить к сущности "Итерация" поле "Полученная чувствительность". Уже сделано.

Вопрос такой: если избавляемся от словаря "Разбавление", то может поле "Разбавление" добавить к сущности "Итерация", а не к сущности "Рецепт"?

Автор: dimich 26.4.2011, 16:22

Ага, идея понятна. Мысль вычислять срок просрочки хорошая. Только основываться надо не на дате добавления рецепта в БД. Можно ведь по памяти довавить рецепт, или из тетрадки, воспроизведенный когда-то там уже не вчера. Но это решаемо. Не будем зацикливаться.

Да, более 10 лет в обнимку с ораклом на продакшене. Да Вы, батенька, тоже не промах. Приятно.

Автор: dimich 26.4.2011, 16:25

Логично. Один и тот же рецепт в разных разбавлениях дает разную картинку. Переносим в Итерацию - я "за".

Автор: dimich 26.4.2011, 16:29

Двухрастворные проявители можно учесть двумя записями Рецепта в Итерации. Для однорастворных - второй Идентификатор рецепта - NULL.
Трехрастворные и т.п. - слайды и цветная проявка - не стоит этой возни со структурой, я думаю.

Автор: 3aBxo3 26.4.2011, 16:30

И еще один момент. Хотелось бы устаканить терминологию.

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

Автор: 3aBxo3 26.4.2011, 16:47

Нет. На мой взгляд стоит сделать промежуточную между проявителем и итерацией таблицу, в которую вынести поля "Разбавление", "Время", "Температура" и "Агитация". Для однорастворного проявителя в этой таблице будет одна запись для каждой итерации, для двухрастворного - две и так далее.

Автор: 3aBxo3 26.4.2011, 17:04

Вобщем, пока как-то так... только кольцевая связь мне не нравится... мозги на сегодня больше не варят. Завтра буду еще думать.

Картинка удалена.

Автор: dimich 26.4.2011, 17:06

С терминологией согласен. Постараюсь придерживаться.
Насчет промежуточной можно подумать. Если выносим Идентификатор пленки в Итерацию, то все встает на свои места.

Автор: Relayer 26.4.2011, 22:13

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

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

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

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

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

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

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

Автор: dimich 26.4.2011, 23:20

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

По пунктам 1,2,3 - поддерживаю полностью.
4 - аналогично. Об этом говорил и то же предлагал ранее.
Остальное - надо на свежую голову. Завтра.

Автор: Relayer 26.4.2011, 23:28

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

Автор: 3aBxo3 27.4.2011, 11:09

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

Я, конечно, не совсем понял Ваше предложение, но рискну предположить, что варианта два:

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




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



В словаре "Тип скана" всего два значения: негатив и бумага (позитив). Вполне возможно, что негатив стоит разбить на два, типа негативный негатив и позитивный негатив . Как этот словарь реализовать, цифрами или словами, это не принципиально. Просто если цифрами, то программисту придется слова прописывать в коде, привязывая их к цифрам.
Так что по этому вопросу у меня нет принципиальной позиции. Пусть прораммист делает так, как ему удобнее.




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



Тут буду думать ещё. Ответ для меня пока не очевиден.



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



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

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

Автор: dimich 27.4.2011, 11:30

Вот. Немного подумал и получается что.
1. Чувствительность все таки надо связывать с Фирмой производителем. Есть стандартный ряд чувствительностей, но есть и стандартные пленки. Fomapan 100,200,400 но нет Fomapan 160. Так что это разумно.

2. Тип пленки нельзя привязывать к итерации. Он должен быть привязан к пленке.

3. Связка Рецепт-Проявитель-Раствор мне что-то не нравится. Может Проявитель и Раствор объединить, а между Рецептом и Проявителем сделать связующую таблицу один ко многим. Возможность описывать многорастворные проявители.

И на перспективу. Надо придумать доменное имя для проекта. Идеи есть? Что-то с воображением совсем туго. Или третий уровень у d-76.ru выпросить?

Автор: 3aBxo3 27.4.2011, 12:10

Коллега! Я в корне не согласен! Атрибут "Чувствительность" характеризует только сущность "Пленка", но никак не сущность "Фирма производитель".



Тоже не согласен. Тип пленки - это 135, 120, 110, листовая и т.д. Если его привязать к пленке, то у нас в таблице "Пленка" для каждой пленки, допустим Fuji 100 Acros, будет N-ное количество записей, а именно "Fuji 100 Acros 135", "Fuji 100 Acros 120", "Fuji 100 Acros 110", "Fuji 100 Acros листовая". Ну и что нам потом с этим делать? Гораздо легче выбрать из списка пленку, а потом все итерации категоризировать по типам пленки.



Многорастворные проявители описываются парой Проявитель-Раствор. Рецепт собирает воедино пару Пленка-Проявитель. Итерация позволяет один и тот же рецепт повторять многократно разным людям при разных условия. Вобщем, я сегодня обдумал модель на свежую голову. На мой взгляд, модель целостна, напротиворечива, нормализована и близка к завершенному состоянию. Теперь бы хотелось узнать кандидатуру программера всего этого безобразия, хотелось бы, чтоб он начал кодить и решать с ним вопросы, возникающие у него в процессе кодирования.



Тут большой простор для фантазии всего сообщества

Автор: dimich 27.4.2011, 12:32

Тоже не согласен. Подобная организация БД позволяет иметь мусор. Давайте решим, валидацией данных либо БД занимается, либо админ.


На мой взгляд все логично.
Есть типы пленки 135, 120, листовая и т.п.
У каждого типа есть Фирма производитель - Ilford, Foma, Fuji...
У каждой Фирмы производителя есть наименования пленки у Ilford'а Delta, HP, FP. У фомы - classic и еще чего-то там и т.п.
У наименования могут быть разные чувствительности
Нормальное такое дерево зависимостей.


Ну в остальном пусть будет так. Тестирование покажет.


Я? Если доверяете это дело, то возьмусь. Только выбор ЯП за мной - это Perl.


Где фантазии? Предлагайте!
devfilm.ru
chartfilm.ru

Автор: 3aBxo3 27.4.2011, 12:51

Вот если честно, то я Вас в этом месте не понял. Ну да ладно.



Лично я доверяю.
Дальнейший спор по поводу модели данных считаю бессмысленной тратой времени. Процесс кодирования расставит все точки над "и".
Ну а так как кодер Вы, то Вам и карты в руки.

Хотелось бы только услышать мнение Алексея. У него были какие-то идеи, под которые, по всей видимости, модель надо будет доработать.



Пока приличных идей нет. Если появятся, то отпишусь.

Автор: 3aBxo3 27.4.2011, 12:57

Кстати, домен devchart.ru вроде свободен.

Автор: dimich 27.4.2011, 13:05

Да, подождем Алексея. Была же какая-то идея с температурными зависимостями, только я не совсем понял. Все таки человек гораздо более опытный в этом плане, чем я. Выслушать надо.

Нет, не свободен.
$ 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 - свободны и еще третьего уровня можно.

Автор: 3aBxo3 27.4.2011, 13:36

Домен devchart хорош, на мой взгляд, тем, что он уже на слуху и многие, наверняка, задают это слово в поисковиках. Я и сам однажды искал это слово

Автор: dimich 27.4.2011, 13:51

Да, devchart хорош.
Как это всё заработает, неплохо было договориться с админами фотоаптеки, чтобы разместить линки на наш массив и с массива на фотоаптеку.
А я потихоньку начинаю реализацию. По мере наличия свободного времени. Пока с рюшечками в интерфейсе заморачиваться не буду - упор на функционал. Раскрашивать потом будем.

Автор: 3aBxo3 27.4.2011, 14:12

Кстати, домен devchart.ru зарегистрировал на себя автор сайта darkroom.ru, он же molaruso, он же Виталий Кузьмин

Автор: odem 27.4.2011, 19:23

Так может этот Виталий Кузмин в благородных целях уступит столь звучный и нужный ему просто про запас домен на благое бескорыстное дело? кто то знаком с этим человеком?

Наблюдаю за этой веткой и тихо соплю в уголочке от удовольствия и гордости за вас ребята. я во все этом мало понимаю, но как активный потребитель того, что вы задумали, молюсь и благословляю вас Думаю, что вы заткнете за пояс digitaltruth.com и заставите всех учить Русский язык

Автор: dimich 27.4.2011, 21:02

Может таки кто обладает дипломатическим талантом, проведет переговоры? Контакты на сайте есть. Если уж нет, то зареглю devchart.net

Таки у Вас будет возможность поучаствовать в развитии проекта, если есть желание. Наполнять информацией, причесывать, следить за порядком ещё потребуются добровольцы Но это чуть позже. Пока я воюю с MySql. После оракла это нечто. Но куда оно денется

Автор: Relayer 28.4.2011, 1:08

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


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


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


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

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

Автор: 3aBxo3 28.4.2011, 9:00

Я стараюсь мыслить не как проектировщик, а как пользователь системы... )))
К слову сказать, кроме того, что я был в свое время главным проектировщиком, я был так же и ведущим программистом. Так-то я чистый сишник, но приложения БД разрабатывал на PL/SQL и MUMPS.

Но мы же здесь, извините, не пиписьками собрались меряться, а проект реализовать удобный и функциональный для пользователя, в том числе и для нас с Вами! Так ведь?

Так что предлагаю диспут завершить и приступать к реализации интерфейса. Когда будет готова альфа версия, примемся за её тестирование и поиск узких мест.
По большому счету, так как не я программер в этом проекте, то мне не сильно важно, как Вы измените модель данных. Самое главное, чтоб система была функциональна и удобна для пользования. Рискну предположить, что всем потенциальным пользователям системы, которые за нами сейчас наблюдают, тоже не важно внутреннее устройство системы. Им важно удобство и функционал.



Выборки для программера, согласен, проще и компактнее, а удобство для пользователя потерялось. А если, вдруг, встанет задача, найти все свежие пленки, у которых до истечения срока годности осталось не меньше года? Что делать-то будете? Заставите пользователя писать в это поле -1, -2, -3 и т.д.?

Ну не та это система, чтоб начинать денормализовывать её для увеличения производительности. Не будет в ней сотен таблиц с миллионами записей! И сложных запросов тоже не будет!



Я понял Вашу мысль прекрасно! Вот только изначально в системе не ставилась задача, описать все растворы, присутствующие в процессе. Мы же не описываем, какую стоп-ванну или фиксаж использовали! Так почему мы должны описывать отбелки, осветлители и прочие жидкости? Мы определяем только пару пленка-проявитель. Если же мы решим, что необходимо будет описывать весь процесс, то модель надо расширять. Но пара провитель-раствор, на мой взгляд, всё равно останется. Нам просто придется замоделировать ситуацию, когда для каждой пары пленка-проявитель в каждой конкретной ИТЕРАЦИИ дальнейшая после проявления обработка различна! Вот и всё.



Полностью согласен с Вами в этом вопросе. Я очень часто в своей практике денормализовывал модель и вносил в неё избыточность, но ТОЛЬКО ПОСЛЕ ТОГО, как она была доведена до 3-ей НФ
Вот только денормализация и избыточность вводятся тогда, когда они необходимы. В данном же случае я не считаю их применение целесообразным.

Повторюсь, для меня главное - удобство и функционал системы.


ЗЫ: я постарался этим своим сообщением максимально точно отразить свою позицию. В дальнейший диспут по поводу структуры бызы данных постараюсь не вступать. Всё отдаю на откуп программерам. И да пребудет с нами сила!

Автор: Aleksiy 1.5.2011, 21:18

Да-ааа, упустил я тему ... Теперь за голову хватаюсь ,и даже не знаю, с чего начать.

Ладно, начну с того, что я СОВСЕМ не программист, а ПОЛЬЗОВАТЕЛЬ. С "этого бока" и буду подходить. Еще раз для начала попытаюсь описАть, что было. А было ОЧЕНЬ похоже на старую версию:
http://www.digitaltruth.com/devchart.php?Film=Legacy+Pro&Developer=&mdc=Search

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

Автор: 3aBxo3 2.5.2011, 6:10

Алексей! Тему Вы не упустили. Всю функциональность, которая была реализована в старом массиве, текущая модель данных позволит реализовать с лихвой.

Предлагаю дождаться от уважаемого девелопера первой версии, протестировать её и дать свои предложения по дальнейшему улучшению.

Автор: dimich 2.5.2011, 11:09

Точно. Данная функциональность будет даже перекрыта, по крайней мере задуманная структура это позволяет и простора для творчества уйма.
Праздники немного выбили из колеи - то агрофитнес, то ремонт. Несмотря на всё, постараюсь первую, частично работоспособную версию выложить после майских праздников, сильно не затягивая.

Автор: 3aBxo3 22.6.2011, 15:50

Боюсь даже спрашивать...

Процесс-то хоть движется? Или уже заглох?
Если заглох, то я хотя бы для себя снова свой файлик заполнять начну... а то остановился на пол пути, жду результата.

Автор: dimich 22.6.2011, 16:18

Движется. Трудностей особых нет.
Не расчитал время. Думал за пару выходных сделаю, а тут какие-то спрошные поездки начались. Уже 2 месяца на выходных дома не был.

Прошу прощения.

Надо бы окрыситься, да поднажать.

Автор: 3aBxo3 22.6.2011, 21:24

Прощения просить не за что! Это же проект на добровольной основе!

Мне главное знать, что не заглох, вот и всё

Автор: Prohor 10.7.2012, 15:23

Оживить бы темку)
Что-то слышно о проекте?

Автор: Aleksiy 10.7.2012, 16:48

При переходе на новый "движок" предусмотрено восстановление "массива проявок".