Организация структуры аналогов номенклатуры ?

[NetWood]

Други, поговорите со мной, пожалуйста.

Есть задача организовать в базе ветвление по аналогам номенклатуры. Например, показывается карточка, а в ней все аналоги документов списком.
Аналоги могут быть, а могут и не быть.
Варианты решения.
1. Тупо в каждом доке поле со списком @Text(@DocumentUniqueID) каждого добавленного аналога в него галочкой - но это капец каждый заполнять. И в этом случае аналог может не знать, что его добавили. В каждом другом доке надо проделать то же самое по отношению к соседям. Простая топорная, но трудозатратная схема.

2. Создаю абстрактный док аналога и в него ответами пихаю все номенклатурные аналоги. В основном доке у каждой позиции показываю абстрактный док с ответами, по наличию своего @Text(@DocumentUniqueID) в ответах и тогда видно всех остальных братанов списком.

3. Вот тут поговорите со мной, пожалуйста.

 

[lmike]

Други, поговорите со мной, пожалуйста.

Есть задача организовать в базе ветвление по аналогам номенклатуры. Например, показывается карточка, а в ней все аналоги документов списком.
Аналоги могут быть, а могут и не быть.
Варианты решения.
1. Тупо в каждом доке поле со списком @Text(@DocumentUniqueID) каждого добавленного аналога в него галочкой - но это капец каждый заполнять. И в этом случае аналог может не знать, что его добавили. В каждом другом доке надо проделать то же самое по отношению к соседям. Простая топорная, но трудозатратная схема.

2. Создаю абстрактный док аналога и в него ответами пихаю все номенклатурные аналоги. В основном доке у каждой позиции показываю абстрактный док с ответами, по наличию своего @Text(@DocumentUniqueID) в ответах и тогда видно всех остальных братанов списком.

3. Вот тут поговорите со мной, пожалуйста.

а принцип "аналога" с чем связан, в основном доке?

 

[rinsk]

Други, поговорите со мной, пожалуйста.

Есть задача организовать в базе ветвление по аналогам номенклатуры. Например, показывается карточка, а в ней все аналоги документов списком.
Аналоги могут быть, а могут и не быть.
Варианты решения.
1. Тупо в каждом доке поле со списком @Text(@DocumentUniqueID) каждого добавленного аналога в него галочкой - но это капец каждый заполнять. И в этом случае аналог может не знать, что его добавили. В каждом другом доке надо проделать то же самое по отношению к соседям. Простая топорная, но трудозатратная схема.

2. Создаю абстрактный док аналога и в него ответами пихаю все номенклатурные аналоги. В основном доке у каждой позиции показываю абстрактный док с ответами, по наличию своего @Text(@DocumentUniqueID) в ответах и тогда видно всех остальных братанов списком.

3. Вот тут поговорите со мной, пожалуйста.

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

 

[lmike]

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

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

 

[Gandliar]

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

 

[VladSh]

Про теги сказали.

Если про гибкие связи доков друг на друга, то можно сделать отдельную базу, в которой при связке доков друг с другом сохранять в одном поле 2 UNID'а. Ну и описания каждого. А потом выводить в каждом доке, список полученный по UNID'у текущего дока.
Это очень удобно - при добавлении линка сами документ не изменяются. При удалении то же самое, - нужно будет удалить всего лишь один документик-связь.

 

[lmike]

Про теги сказали.

Если про гибкие связи доков друг на друга, то можно сделать отдельную базу, в которой при связке доков друг с другом сохранять в одном поле 2 UNID'а. Ну и описания каждого. А потом выводить в каждом доке, список полученный по UNID'у текущего дока.
Это очень удобно - при добавлении линка сами документ не изменяются. При удалении то же самое, - нужно будет удалить всего лишь один документик-связь.

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

 

[VladSh]

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

Думал об этом, но тогда неясно, как создавать связи "один к многим" - потребуется создавать несколько документов с одним и тем же UNID...

Другое дело, если взять 2 UNID'а, взять от них хеш, и создать документ с получившимся UNID'ом. Тогда комбинация будет всегда уникальной. И связь можно быстро получить либо с первой, либо со второй попытки (по хешу над поменянными местами UNID'ами). Тогда вид не нужен.

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

 

[lmike]

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

ну тут шардинг/сизинг... (кучка БД только для дайжестов)
ну или уже через интеграцию с РСУБД