Столкнулась с доработкой базы, где измерение регистра сведений - строка. Длина 25 символов. Это номер входного билета, он уникален, в день может быть около 1000 новых билетов.
Этот номер билета в виде строки присутствует во многих других объектах - в документах, как измерение другого регистра сведений, как реквизит регистра накопления, уже созданы отчеты с этими данными, а также обработки обмена с другими системами (не 1С).
Мне сейчас надо принять решение - следовать уже существующей логике и делать измерение моего РС тоже строкой (хотя по стандартам 1С это неправильно) или создавать свою систему объектов и связывать с существующей. Времени на глобальный рефкторинг старого кода (и, соответственно, обработок конвертации старых данных в новые) сейчас нет, и, возможно, несколько месяцев не будет.

Какое решение целесообразнее принять в таком случае - делать как правильно или делать как сделали, а через несколько месяцев вернуться к переделке всего и вся? Или 25 символов - это не 500 и можно оставить? Что бы вы посоветовали и почему?

(0) Делать как сделали. Возвращаться к переделке не нужно.

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

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

согласен с (2) - один из простейших способов решения проблемы

(2) +++++

(2) Я знаю, что так правильно, знаю, почему, и с нуля делала бы так же.
Но ситуация другая.

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

надо смотреть на пару шагов вперед... какие потребности могут возникнуть

ссылка на справочник более перспективна

(6) https://ru.wikipedia.org/wiki/Нормальная_форма

(8) не показатель, к этому надо стремится, но это вообщем не является обязательным.

стесняюсь спросить - причем тут НФ?

тут выделять сущности незачем - от нее только один реквизит есть - номер

(9) Да вообще нет ничего обязательного кроме дышать, пить h20 и иногда глотать органические соединения.

(2) дык если 25 символов, то норм (вроде даже где-то в типовой видел), а вот если неограниченная длина, то да

(6)
1. размер в составном индексе строки больше чем ссылки
2. контроль ссылочной целостности
3. сортировка работает по разному на разных средах
4. часть таблиц можно запихнуть внутрь справочника (например дату билета, и прочее)

могу продолжать....

5. В случае потребности добавления в измерения регистров еще каких-нибудь строк можно наткнуться на ограничение длины индекса СУБД

(7) Да, я уже столкнулась с тем, что изменение длины номера билета превращается в геморрой.

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

Во втором случае еще есть опасность, что если заказчик не согласится с необходимостью отдавать деньги за рефакторинг, то у него так и останется часть объектов со строкой, часть со справочником, и пришедший на мое место новый 1сник проклянёт меня страшными прокляниями.


Интересует не академическая правильность, а чисто практическая.

(15) Чисто практически:
1) Я не делаю говна даже за деньги, потому что репутация/религия/совесть/бзик (нужное подчеркнуть);
2) Любой каприз за ваши деньги.

Выбираете что вам ближе и ура.

(13) " размер в составном индексе строки больше чем ссылки "
- почему, в данном случае

(16) понимаешь, вот ну нахрена мне мелкий костыль, который сделан с соблюдением всего и вся и стоить он будет 40 тыс, если ему красная цена - 3 тыс?

(18) потом этот мелкий костыль принесет крупный геморрой...

(15) если поджимает - то делаешь так как было, по принципу - ЕДИНООБРАЗИЕ - везде строки - это на порядок лучше (исправить потом при возможности) чем часть строки, а часть типа (16) налепит ссылками.

(19) а ты его не трогай... ;-)

(19) у меня таких "костылей" есть - кучу лет стоят - и только сейчас начал задумываться о рефакторинге - ибо стоимость костыля на тогда - была на порядки меньше чем некостыля. баланс - качество-время-деньги - и ничего иного.

(20) Типа (16) пошлет типа (18) на поиски <зачеркнуто>копрокодеров</зачеркнуто> людей с менее принципиальной позицией по вопросам рабочей этики.

(15) "и переделку везде номеров на ссылку я туда не втисну" - разве это так сложно?

(23) как пример. есть у меня псевдожурнал на ТЗ. работает. но некузяво и возможности сильно коряво реализованы. Перетер с местными спецами - пошел к начальству - говорю - давайте сделаем по уму,с нормальными фильтрами, красивенько, удобненько, комфортнее будет (на ТП сделать надо) - цена вопроса всего-то ~10 тыс. Руководство сказало - НЕ НАДО! и чего мне теперь - гумусом изойти, от того что руководство не понимает необходимости делания "как надо"..? или даром работать?

(25) А ты доходчиво рассказывал им про финансовый выхлоп от этой переделки?

(26) а какой финансовый выхлоп от замены по сабжу?

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

(24) Объектов с "неправильными" номерами несколько десятков. Все они завязаны на несколько обменов с разными системами (не 1С). Все это надо тестировать, прежде чем что-либо менять.

У меня уже есть список "горящих" задач, есть бюджет, есть сроки. Чисто техническую задачу, не облегчающую работу пользователей, никто в приоритеты сейчас не поставит. Такой баланс ресурсов.
После решения "горящих" задач- все может быть.
Бесплатно работать не готова. Сверхурочно тоже. Я не фикси.

(29) ты понимаешь, что ты сейчас тру-программерам в душу плюнула? ;-) причем смачно! они же готовы делать все правильно и задешево!

(27) Так поэтому тебя и бороданули

(31) ты предлагаешь мне посчитать финансовый выхлоп, провести обследование и написать ТЗ - бесплатно?

(32) Вроде не это обсуждали

(33) обсуждаем трудозатраты на то чтобы делать "правильно"... внезапно оказывается что все имеет свою цену...

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

(34) "внезапно оказывается" // Почему внезапно-то? Тот, кто заказывает банкет (платит), должен же понимать, за что (зачем) он платит, разве не?

(29) Надо с другого конца подходить, говоришь: "Есть возможность сэкономить N рублей в будущем, если потратить N/3 сейчас. Будем делать?".

>> и чего мне теперь - гумусом изойти, от того что руководство не понимает необходимости делания "как надо"..? или даром работать?

Не надо было делать

>>псевдожурнал на ТЗ. работает. но некузяво и возможности сильно коряво реализованы

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

(38) к (25)

(35) Это верно. Поэтому пока склоняюсь к варианту рефакторинга, но через пару месяцев.

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

(38) вот ты умный. сидел бы я тупобыдлокодером, программил бы по заданиям - зашибись былобы. на тот момент когда это надо было делать - там не то что куча гумуса, там вообще страшно было, так что на тот момент псевдожурнал на ТЗ - это вообще был "алмаз неграненый"... ;-)

(36) какие профиты финансовые от сабжа рефакторинга?

(37) Да, примерно так буду обосновывать (40)

Всем спасибо за обсуждение.

(42) С таким подходом быдлокодить по заданиям как раз самое оно. Пилишь костыль, втыкаешь поглубже в систему, "и так сойдет"!

(35) кстати как там у Вас дела? база доросла до терабайта?

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

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

а если это справочник - то система не даст его удалить пока на него есть ссылки...

(47) бух - да ))) вроде работает все, значит не зря тут сидим...

(48) Вам это абсолютно не нужно. Это нужно вашему заказчику. И вы можете по-честному делать так как нужно заказчику, который оплачивает вашу работу, своевременно предупреждая о рисках. А можете делать как нужно лично вам.

(51) большинство заказчиков не подозревает о рисках, таящихся внутри "быстрых и дешевых решений".
Ну, или понимает, но очень хочет, чтоб все было быстро, дешево и без рисков...

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

Строки в РС - нормальное решение, не парься,
во многом даже лучше ненужной сущности в виде справочника.

(49) +1 Если есть дальнейший ход сущности.
Если есть кроссовые ссылки, то строка в РС не катит.

(54) как раз есть сущность - "билет", имеющий признак - "номер" типа "строка-25"

(0) Не очень хорошо, но не критично.
Работает - не трожь.
Возвращаться не надо. Пусть работает.
Разве что если ты там фикси и больше заняться нечем.

(57) люблю франчей. "сделаем наполовину, зато через *опу"©

(58) франчи делают так не половину а все :)))

(58) Вопрос не в "сделать", вопрос в "сломать работающее".
Не надо ломать лишнее.

(60) А я говорю - резать! резать не дожидаясь перитонита!!!

я такие говно-решения всегда стараюсь переделать... и пока все еще живы :)

(61) Это ты будучи на фиксе так делаешь или на сдельной оплате продавливаешь рефакторинг / улучшение уже работающего какое-то время кода?
Но и на фиксе не всем на такое добро дают (пример в (25))

(61) Идеала не существует.
Всегда есть, что улучшать.
Только обычно это нецелесообразно.
1. Это лишние деньги.
2. Во вторых есть вероятность что-то поламать.
Разве что это фикси и ты там постоянно работаешь.
ИМХО, придти к клиенту и без необходимости начать все рефакторить на почасовке это вредительство.

(62) и на фикси так делал и работая во франче так делал для Главмосстроя....

и заказчики были довольны, меня до сих пор пытаются к себе зазвать, именно по тому, что сделал так, что хорошо стало всем...

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

(60) дело не в "ломать лишнее". дело в "делать правильно".
если есть отдельная сущность - она и должна быть отдельной сущностью.
а подход франчей - "из г**на и палок, но на почасовке".... ну я вот так не смог. Любо нормально, либо никак.  
Хотя я вполне понимаю суть франча - сейчас возьмут деньги за то, что сделают дерьмово, после возьмут деньги за анализ, почему ж сделано дерьмово, возьмут деньги за план как сделать правильно, и возьмут деньги за рефакторинг.

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

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

часть таких доработок неускоряются никогда - ибо устраивает...

(68) Посмотрел сейчас как у нас построена схема работы с БСО. И надо же, в регистре накопления измерение - строка. А самое интересное, все прекрасно работает, никто не жалуется.