Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft Access Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3      [все]
 Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Компания выпускает ИЗДЕЛИЯ.
ИЗДЕЛИЕ состоит из большого числа компонентов - 10000-15000
Туда входят сборочные единицы(производства компании) - уровень вложенности до 10-12, детали и покупные изделия
Сборочные единицы 50% разрабатываются заново для каждого изделия, 50% берутся из ранее разработанных.
Сейчас организовано так
Таблица MAIN - сборочные единицы и детали в неструктурированном порядке - типа общий каталог
Таблица MAIN1 - описание конкретных ИЗДЕЛИЙ, где содержится точная информация о составе(дереве) ИЗДЕЛИЯ с его полной структурой.
связь по id компонента
Пока это было только для технологов - это работало норм. Сейчас планируется расширение функций и подключение к базе с таблицами конструкторского отдела. Они будут работать не в Аксе, а через VBA модуль в программе CATIA
ВОПРОС - Как организовать правильное (оптимальное) использование сборочных единиц разработанных ранее в новых проектах.
Примечание 1- уникальность состава сборочной единицы естественно обеспечивается, при изменении состава единицы хоть на 1 винт - это уже новая сборочная единица.
вижу 2 варианта
1) получать данные о структуре сборки из табл MAIN1(брать из какого-то уже выполненного изделия) и при необходимости копировать их в новый проект.
2) создать промежуточную таблицу, связанную с MAIN, и содержащую информацию о составе сборочных единиц
Примечание 2 Хранить точную структуру сборочных единиц в MAIN(общем каталоге) не представляется возможным, так как одна и та же сборочная единица может входить в десятки или сотни вышестоящих сборочных единиц с разным уровнем вложенности.
Вопрос локальный, я полагаю что не стоит идти сильно вглубь и вширь всей базы.....
5 сен 19, 09:43    [21964244]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ROI
Member

Откуда: г. Тюмень
Сообщений: 1784
Serg197311,

Однозначного ответа вы не получите.
Ту столько копий сломано на счет (сборок, уровней вложенности, EVA, древовидные структуры, Тенцер)
Поиском по всему сайту вы это несомненно найдете.
5 сен 19, 09:55    [21964257]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ROI
Однозначного ответа вы не получите.

Да его и не существует наверное, однозначного-то...
Ну хоть какой-нибудь бы
5 сен 19, 09:58    [21964262]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Пока склоняюсь к доп таблице со структурой сборок.....
В модуле технологов вообще ничего менять не придется, а поддерживать уникальность состава сборки так ИМХО проще и надежней....
5 сен 19, 10:09    [21964273]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Joss
Member

Откуда: г. Минск
Сообщений: 4891
Давным-давно работал на заводе и занимался этим делом.
Работал тогда инженером-конструктором в ОГК.
Есть такие вещи, как спецификации. На основе их разрабатываются производственные описи (ПО), ведомость покупных (ВП), ведомость документов (ВД) и ведомость метизов (крепежа) не помню обозначение, материалы 9так же не помню как обозначалась)
Помню была таблица наименований - код детали, сборки, метиза, покупного изделия и т.п - название (ну и дополнительные поля были: вес, материал и т.п)
Была таблица Состав : код сборки, код входящей детали, количество деталей.
Вот на основе этих таблиц Всё и получали. Очень полезная вещь. Шла как в отдел кооперации, так и в отдел комплектации, к технологам, мастерам в цеха, на склады и т.д.
Всё это было реализовано ещё на ЕС ЭВМ. Потом был разработана программа ЦКС (центральный комплектовочный склад) уже на СМ ЭВМ, куда загружали данные с ЕС. Всё работало чётко, пока не наступили 90-е. Потом ушёл с завода.
10 сен 19, 14:54    [21967789]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ldfanate
Member

Откуда:
Сообщений: 129
Serg197311
Компания выпускает ИЗДЕЛИЯ.
ИЗДЕЛИЕ состоит из большого числа компонентов - 10000-15000
Туда входят сборочные единицы(производства компании) - уровень вложенности до 10-12, детали и покупные изделия
Сборочные единицы 50% разрабатываются заново для каждого изделия, 50% берутся из ранее разработанных.
...
Примечание 2 Хранить точную структуру сборочных единиц в MAIN(общем каталоге) не представляется возможным, так как одна и та же сборочная единица может входить в десятки или сотни вышестоящих сборочных единиц с разным уровнем вложенности.
...


Так понимаю, чтото вроде версионирования документов придётся прикручивать - т.е. хранить всю структуру Сборочных единиц (СЕ), а не только дерево разузловки Изделий на всю глубину. Т.к. с Конструкторами наверняка появятся статусные схемы СЕ (рабочая редакция, на согласовании, прошла техсовет, утверждена и проч.).
10 сен 19, 15:54    [21967844]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
vmag
Member

Откуда: MP
Сообщений: 3235
Serg197311,

Как то всё сумбурно и не очень понятно, но вырисовывается алгоритм типа такого (низ/верх):
1. Анализируем существующие MAIN на предмет их достаточности для сборки нового проекта.
Если не хватает, создаем (возможно и на основе уже существующих) недостающие (новые) MAIN.
2. Ищем в MAIN1 наиболее подходящий старый проект с совпадением по MAIN по максимуму.
3. На его основе создаем новый MAIN1, выбрасываем из него ненужные MAIN и добавляем недостающие MAIN.

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

Мдя... какой вопрос, такой и ответ...
11 сен 19, 01:02    [21968177]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Лапух
Member

Откуда: Стойбище № 7
Сообщений: 880
Похоже тут главное понять, что ТС подразумевает под словечками - Уровень вложенности 10-12.
Хоть бы пукнул показал или поподробнее расписал как это выглядит в натуре,
Это 10-12 табличек для описания изделия, типа:
ВидИзделия
МаркаИзделия
МодельИзделия
РазмерИзделия
ФасонИзделия
ЦветИзделия
...
Далее что то не хватает воображения. Картинка с другого сайта.

или это всего типа 2 таблицы
Изделие
ПодчинённоеИзделие

Хотя довольно прикольно читать, как ТС не может внятно объяснить, а помогальщики не могут внятно подсказать.
Картинка с другого сайта.
11 сен 19, 06:00    [21968197]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Лапух
Хотя довольно прикольно читать, как ТС не может внятно объяснить, а помогальщики не могут внятно подсказать.
Картинка с другого сайта.

Ну кому непонятно..... тот может и не отвечать
Вот Jossу, Idfanatу, vmagу точно все понятно и их ответы-советы все по существу)
11 сен 19, 06:35    [21968200]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Лапух
Member

Откуда: Стойбище № 7
Сообщений: 880
Serg197311
...и их ответы-советы все по существу...

И что же вы поняли существенного по существу?
Может я тоже так хочу, типа научиться видеть суть вещей, но чёй та не пойму чего вы поняли и чего вам подсказали существенного. Картинка с другого сайта.
11 сен 19, 06:57    [21968207]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ldfanate
Member

Откуда:
Сообщений: 129
Serg197311
Пока склоняюсь к доп таблице со структурой сборок.....
В модуле технологов вообще ничего менять не придется, а поддерживать уникальность состава сборки так ИМХО проще и надежней....


Так сделайте табличку со внутренней иерархией на любую глубину. Ближайший аналог SAP ТОРО - там любое сложное изделие (ну например турбоагрегат) разузловывается в виде дерева Технических мест и подчинённых им Единиц оборудования на любую глубину. Теоретически можно до последней гайки и шайбы - но такое не всегда нужно в эксплуатации, поэтому бывает разузловывают какраз до блочных заменяемых Изделий. А сбоку join-ом ваши нынешние таблицы. Избыточность только добавит надёжности, раз у вас там настолько сложное производство.
11 сен 19, 07:01    [21968210]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Слегка сумбурно просто потому, что на данный момент в конторе нет четкой концепции документооборота, на данный момент ее просто никакой нет, и я собственно ее и создаю сейчас.
В планах стоит создавать электронную структуру изделий, хранить ее в базе данных и работать в дальнейшем с ней. Чертежи - что бумажные, что файлами .CATDrawing - совсем отдельная история, с кучей своих заморочек, и поэтому сейчас я рассматриваю только 3D модели сборок и самих деталей. Понимаю, что есть хороший выход - купить готовую PLM(PDM) и внедрить ее. На то что бы так не поступать есть множество причин, и они все не относятся к данной теме.
И собственно я колеблюсь между 2-мя направлениями
1) Изменения в сборке(единице номенклатуры с уникальным номером) не допускаются, при необходимости внести изменения создается новая сборка со своим номером(номером версии). Естественно присутствует процедура согласования/информирования всех необходимых лиц. После выполнения проекта все не вошедшие в него промежуточные версии сборки ( по желанию конструкторского отдела) выводятся из номенклатуры и файлы удаляются. История внесения изменений хранится в базе в текстовом виде.
В этом случае отдельная таблица со структурой сборок не нужна- можно найти структуру выбранной сборки в таблице с реализованными проектами и использовать ее. Еще плюс - на каждую сборку в номенклатуре обязательно есть свой единственный файл .CATProduct, точно ее описывающий, вся архитектура сборки хранится не только в базе, но и в этом файле.
Минус - даже если убрать или добавить 1 шайбу - требуется создать новый файл головной сборки. Но это легко реализуется программными методами из базы.
2) Изменения в сборке допускаются, структура основной сборки хранится в отдельной таблице - допустим SBORKI. Каждое изменение оформляется/согласовывается и хранится с указанием его применяемости. Именно так и был организован старый советский документооборот. Но так было сделано ИМХО потому, что основой был бумажный чертеж. Создать компьютерный документ, описывающий структуру сборки (типа файла .CATProduct) тогда просто не было возможности.
При этом у нас теряется уникальность файла сборки-нельзя открыть структуру из SBORKI и использовать ее. Надо обязательно поднимать всю историю изменений по всему дереву сборки. Избежать создания нового файла сборки все равно не получается, придется хранить и файл со структурой основной сборки, и файлы с реальной структурой, реализованной в проектах. Рано или поздно, когда изменений будет больше какого-т количества, все равно придется создать новую основную сборку и хранить и ее файл.
В общем я пока не определился.....
несколько дней назад думалось про создание доп таблицы SBORKI
на данный момент склоняюсь к варианту по п1, без нее....
Думаю-соображаю....
11 сен 19, 07:22    [21968214]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4592
Joss
Помню была таблица наименований - код детали/ сборки - название (ну и дополнительные поля были: вес, материал и т.п)
Была таблица Состав : код сборки, код входящей детали, количество деталей в сборке

работала точно с такой же схемой таблиц
+ материалы по детали
+ трудоемкость и расценки по детале-операции
+ мелкие справочники

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

и конечно поиск по переменному количеству полей по принципу ИЩУ ПО ТОМУ, ЧТО ЗНАЮ

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

зацепившись за деталь далее видели
-что входит в найденное, т.е. это сборка
-куда она сама входит в качестве детали или подсборки

поиск(фильтрация) работал по всех цехах и большинстве отделов автономно(общей сети тогда еще не было)
в отделах конструктора и технолога -по сети отделов
11 сен 19, 07:22    [21968216]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Лапух

Может я тоже так хочу, типа научиться видеть суть вещей, но чёй та не пойму чего вы поняли и чего вам подсказали существенного. Картинка с другого сайта.

Толцытеся.... и отворится вам!
11 сен 19, 07:23    [21968217]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ldfanate
Теоретически можно до последней гайки и шайбы - но такое не всегда нужно в эксплуатации, поэтому бывает разузловывают какраз до блочных заменяемых Изделий. А сбоку join-ом ваши нынешние таблицы. Избыточность только добавит надёжности, раз у вас там настолько сложное производство.

Сейчас, в табл MAIN1 как раз и хранится полная разузловка уже выпущенных изделий, до последней шайбы, реализованная по древесной структуре.
11 сен 19, 07:26    [21968218]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4592
Serg197311
Сейчас, в табл MAIN1 как раз и хранится полная разузловка уже выпущенных изделий, до последней шайбы, реализованная по древесной структуре

не очень поняла , как вы храните

мы хранили только уникальные строки по КУДА(код сборки)+ЧТО+СКОЛЬКО без привязки к изделию
остальное получали расчетно, например
- изделия+сборки+детали россыпью, т.е. перевод уже собранных единиц в назад детали с подсчетом задействованных деталей
- любой узел можно было пересчитать в ранге изделия и выдать по нему итоги по материалам, трудоемкости и расценку
- не трогая основное изделие, можно заменить ссылку на некую сборку(деталь) на вариант сборки/детали или подключить вместо собственной сборки покупную, которую не надо раскрывать для цехов(только для конструкторов)

это привело к тому, что таблица СОСТАВ была достаточно компактной, особенно учитывая то , что вариантов изделий было достаточно много, например одна из деталей входила в 800 сборок в более чем 200 изделий
11 сен 19, 08:45    [21968249]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
code OWN sernn codever qt
151 145 1 59 1
152 146 1 60 1
153 146 1 61 1

Типа так
Code - код текущей записи в MAIN1
OWN - код вышестоящей записи из MAIN1
sernn - код изделия
codever - код детали(сборки) из основного каталога MAIN
qt - количество
11 сен 19, 09:05    [21968256]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ПЕНСИОНЕРКА
мы хранили только уникальные строки по КУДА(код сборки)+ЧТО+СКОЛЬКО без привязки к изделию
остальное получали расчетно, например

А вот этого уже не понял я.....
11 сен 19, 09:16    [21968264]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4592
Serg197311,

в вашем исполнении я не поняла, что есть количество
- количество в текущей сборке
- количество в изделии

пусть деталь 61 входит в 2 сборки одного изделия, а деталь 62 одна на 3 изделия
codeOWNsernncodeverqt
код текущей записи в MAIN1код вышестоящей записи из MAIN1код изделия- код детали(сборки) из основного каталога MAINколичество
1511451591
1521461601
1531461611
1541451611
1541451620,3333
11 сен 19, 09:22    [21968266]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ПЕНСИОНЕРКА
Serg197311,

в вашем исполнении я не поняла, что есть количество
- количество в текущей сборке

11 сен 19, 09:40    [21968278]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ldfanate
Member

Откуда:
Сообщений: 129
автор
1) Изменения в сборке(единице номенклатуры с уникальным номером) не допускаются, при необходимости внести изменения создается новая сборка со своим номером(номером версии). Естественно присутствует процедура согласования/информирования всех необходимых лиц.


Такой вариант видится наиболее надёжным (и помоему наиболее методологически-близким к традиционному бумажному обороту конструкторской документации). Т.к. новое всегда пойдёт в БД как обособленный бизнес-объект, и не будет ломать логику использования уже ранее утверждённых бизнес-объектов.
К тому же, к бабке не ходи, потом начнут появляться связи между разными СЕ. Ну например, новая СЕ оказывается не полным аналогом прежней СЕ, а ограниченно применимом только для узкой номенклатуры Изделий в исполнении УХЛ (потому что гайку хромированную поменяли на гайку ржавую обыкновенную, и для субтропического исполнения оно не применимо, т.к. приржавеет после первого муссона :).
11 сен 19, 09:40    [21968279]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ldfanate

Такой вариант видится наиболее надёжным :).

Вот и я пока к нему склоняюсь......
11 сен 19, 09:46    [21968285]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4592
Serg197311,

мы считали так



sernn \код изделия\1

строкаOWNcodeverqt сборкуна изделие
код текущей записи в MAIN1код вышестоящей записи из MAIN1- код детали(сборки) из основного каталога MAINприменяемостьколичество по сборкам
1450054022
146006410,50,5
1511455911*2=2
1521466011*0,5=0,5
1531466111*0,5=0,5
1541456111*2=2
154145620,33330,3333*2=0,6666


детальизделиеколичество всего
4012
4110,5
5911*2=2
6011*0,5=0,5
6111*0,5+1*2=2,5
620,33330,3333*2=0,6666
11 сен 19, 09:46    [21968286]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Я в таблице храню только количества деталей/сборок в вышестоящей сборке. Если надо посчитать винты такие-то в изделии или в сборке такой-то - это делаю функцией на vba.
11 сен 19, 09:50    [21968291]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4592
ldfanate
например, новая СЕ оказывается не полным аналогом прежней СЕ, а ограниченно применимом только для узкой номенклатуры Изделий в исполнении УХЛ (потому что гайку хромированную поменяли на гайку ржавую обыкновенную, и для субтропического исполнения оно не применимо, т.к. приржавеет после первого муссона :).

вряд ли изделие в тропическом исполнении отличается только гайкой от базового -отличается и весь техпроцесс, а значит это другое изделие и другие составляющие и другой техпроцесс, даже в гравировке деталей добавляются символы
11 сен 19, 09:54    [21968295]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4592
Serg197311
количества деталей/сборок в вышестоящей сборке

а если вышестоящая входит еще более вышестоящую, причем к количестве не равном 1
11 сен 19, 09:58    [21968298]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4592
Serg197311,

для однотипных изделий выдавались планы изготовления деталей примерно такого типа
изд 01и02и03и04и05и05еи05 тропики08 зипи09 проба
план заполняется, остальное расчетом10уточн21523100
перечень сборок и деталей
с11021523
с111021523
с1220421046
с13408420812
с2110--3
с22-22
с312--
д11110222002
д111е3
д11220444002
д112е6
д11340888002
д113е12
д999120242412002
д114е
покупн11022
покупн22044
крепеж1150-
крепеж2-150
11 сен 19, 10:56    [21968355]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ПЕНСИОНЕРКА
а если вышестоящая входит еще более вышестоящую, причем к количестве не равном 1

Именно так и есть. Говорил же - написал функцию, которая пробегает по сборкам вверх(используя OWN) и считает реальное количество
11 сен 19, 11:22    [21968381]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Public Function Getqb(nm1 As Long) As Long
Dim rst As DAO.Recordset
Dim qq As Long
Dim cn As Long
cn = nm1
qq = 1
20 Set rst = CurrentDb.OpenRecordset("SELECT * from MAIN1 where MAIn1!code=" & cn & ";")
   If rst.EOF = False Then
      qq = qq * rst!qt
      cn = rst!OWN
      GoTo 20
   Else
       Getqb = qq
       Exit Function
   End If

End Function
11 сен 19, 11:25    [21968382]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ldfanate
Member

Откуда:
Сообщений: 129
ужастный код. За использование goto программистов-базицников линейкой по рукам ещё в конце 90ых начали бить (ну кроме on error goto разумеется). :)
11 сен 19, 11:44    [21968393]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4592
Serg197311
Таблица MAIN1 - описание конкретных ИЗДЕЛИЙ, где содержится точная информация о составе(дереве) ИЗДЕЛИЯ с его полной структурой

что то мне показалось, что у вас отдельная таблица на каждое изделие
11 сен 19, 12:13    [21968412]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ldfanate
ужастный код. За использование goto программистов-базицников линейкой по рукам ещё в конце 90ых начали бить (ну кроме on error goto разумеется). :)
Полностью согласен...... Ужасный.....Но я по образованию не программист, поэтому сделал так - работает... Подскажете как переделать - буду очень благодарен.
11 сен 19, 12:36    [21968436]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ПЕНСИОНЕРКА
что то мне показалось, что у вас отдельная таблица на каждое изделие

Нет, таблица одна. Но для каждого изделия в ней своя структура дерева.
11 сен 19, 12:38    [21968438]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4592
Serg197311
Но для каждого изделия в ней своя структура дерева

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

я попробовала, создала пример базы,добавив несколько типичных ситуаций
--как и предполагала - нужных(ручных) по сборке 6 итогов не получила
OWNcode1codeverqtна изделие
1511
16***11
56***6c33
514540с22
614641с0,50,5
14515159д12
14515461д12
14515562д0,33330,6666
14615260д10,5
14615361д10,5
11 сен 19, 13:41    [21968514]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
vmag
Member

Откуда: MP
Сообщений: 3235
ldfanate
ужастный код. За использование goto программистов-базицников линейкой по рукам ещё в конце 90ых начали бить


Это чисто с точки зрения читабельности кода, ну типа грамотности что ли, но иногда не грамотный гораздо продуктивнее грамотного... так в тех же 90-х мною экспериментально было установлено на ес-1060 в языке PL1, что оператор цикла DO WHILE работает в полтора раза медленнее чем цикл на одной переменной с оператором GOTO, видать тот кто реализовывал в компиляторе конструкцию DO WHILE родил из мухи слона, нам то это не очевидно, нас устраивает изящность кода, а так - то да нужно стремиться к искусству...
11 сен 19, 13:56    [21968538]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ПЕНСИОНЕРКА
тогда еще более неясно, как ваша функция работает, особенно если в изделии может повторяться одна и та же сборка/деталь несколько раз

Вот картинка. структрура видна
выделенная нода - прокладка - 2 шт в сборке подушка
Сборок Подушка в сборке Доработка кресла - 2 шт
Функция на вход использует код записи( на картинке в конце после /)
Берет по нему количество -2, и по коду записи же находит код вышестоящей записи по дереву -
код сборки Подушка, берет их количество - 2, перемножает, находит код вышестоящей записи - Доработка...
и тд пока есть вышестоящая запись.

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









ПЕНСИОНЕРКА
дробные применяемости вообще не предусмотрены
Ага. Не может быть 0,5 болта, 0,2 гайки или 1,4 сборочных единицы. Материалы считаются совсем по другому

К сообщению приложен файл. Размер - 131Kb
11 сен 19, 14:03    [21968542]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4592
Serg197311
Не может быть 0,5 болта, 0,2 гайки или 1,4 сборочных единицы

но зато может быть
-упаковочный ящик на несколько изделий(упаковка у нас относилась на изделие)
-аналогично групповой ЗИП(один КОМПЛЕКТ на несколько изделий)
11 сен 19, 14:22    [21968561]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ПЕНСИОНЕРКА
но зато может быть
....

У меня в базе есть такое понятие - процесс изготовления детали.
Вот к нему может быть привязано дробное количество как материала, так любого покупного(или не покупного) изделия.
Так и делаю сейчас.
11 сен 19, 14:30    [21968569]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Stanislav P
Member

Откуда: Сочи
Сообщений: 82
На мой взгляд Вы пытаетесь управленческую задачу по построению бизнес-процесса решить на программном уровне, а потом отдать этот процесс в работу.

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

Поэтому, сначала обсудить с руководством сам процесс, а потом уже программировать.
11 сен 19, 14:41    [21968576]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Stanislav P
На мой взгляд Вы пытаетесь управленческую задачу по построению бизнес-процесса решить на программном уровне, а потом отдать этот процесс в работу..

Абсолютно верное замечание! Почти. Руководство в курсе, и сейчас фактически перестраивается часть бизнес процесса(документооборот) в связи с появлением новых задач.

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

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

Stanislav P
При использовании второго варианта выше приведённой проблемы нет, но появляется необходимость хранить временную (версионную) составляющую изделия. То есть, неделю назад выписали счёт на диван с болтами и его продали, а сегодня внесли изменение в изделие и вместо болтов там стоят шурупы и тогда изменится состав документа двухнедельной давности (должны быть болты, а стоят шурупы), так как оба счета ссылаются на одну и ту же запись, но с разным составом..

Вот че-то похожее пока и происходит, правда в отсутствие сквозной базы данных.


Stanislav P
Поэтому, сначала обсудить с руководством сам процесс, а потом уже программировать.

Высшее руководство не знает, как надо - как всегда на среднем звене создаем концепцию, которая нам наиболее удобна - нам же в итоге и работать. А так руководство конечно в курсе всего что происходит....
11 сен 19, 14:59    [21968589]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ldfanate
Member

Откуда:
Сообщений: 129
Stanislav P
Оба предложенные варианта имеют недостатки.


Так там у автора упор был на потребности технологов и конструкторов.
Пока это было только для технологов - это работало норм. Сейчас планируется расширение функций и подключение к базе с таблицами конструкторского отдела.
Для продажников придётся сбоку ещё один тип связей прикрутить, чтобы увязать такие однородные Изделия под потребности продажников, - номенклатура готовых изделий на складе готовой продукции (обычные МТР), регистрация поступления из производства на склад и далее классический складской учёт.
11 сен 19, 15:04    [21968593]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ldfanate
Для продажников придётся сбоку ещё один тип связей прикрутить, чтобы увязать такие однородные Изделия под потребности продажников, - номенклатура готовых изделий на складе готовой продукции (обычные МТР), регистрация поступления из производства на склад и далее классический складской учёт.

Не, не придется - нет продажников.... Нет готовых изделий на складе и не может быть.... на складе могут быть только детали и отдельные сборочные единицы. Специфическая продукция....
11 сен 19, 15:15    [21968600]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Stanislav P
Member

Откуда: Сочи
Сообщений: 82
Serg197311, отдельные сборочные единицы так-же согласовываются и изменяются как и конечный продукт? Так же могут быть изменены в процессе разработки?
11 сен 19, 15:36    [21968620]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ldfanate
Member

Откуда:
Сообщений: 129
Serg197311
нет продажников.... Нет готовых изделий на складе и не может быть.... на складе могут быть только детали и отдельные сборочные единицы. Специфическая продукция....


А что, для специфической продукции правила учёта, действующие в РФ, не применяются? Испод-полы торгуем?
Складской учёт, отгрузка заказчику, соответствующие ведомости, товаро-транспортные накладные и проч. не выписываете вовсе?
Себестоимость выпуска готовой продукции и прочие показатели, зависящие в т.ч. и от эффективности производства, складских запасов, ТЗРов и проч., - не считаете?
11 сен 19, 15:47    [21968628]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Stanislav P
Serg197311, отдельные сборочные единицы так-же согласовываются и изменяются как и конечный продукт? Так же могут быть изменены в процессе разработки?

Да, также....Там ТЗ с приложениями листов на 10-15, и в процессе выполнения бывают к нему изменения....
11 сен 19, 15:48    [21968629]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ldfanate
А что, для специфической продукции правила учёта, действующие в РФ, не применяются? Испод-полы торгуем??

Все применяется. Потребитель - на 90% государство. Причем так стало в последнее время, и вот тут и появились новые задачи.....

ldfanate
Складской учёт, отгрузка заказчику, соответствующие ведомости, товаро-транспортные накладные и проч. не выписываете вовсе??

А разве для этого нужны продажники?

ldfanate
Себестоимость выпуска готовой продукции и прочие показатели, зависящие в т.ч. и от эффективности производства, складских запасов, ТЗРов и проч., - не считаете?
Считаем, считаем.... для чего еще эта база нужна-то... за исключением складских запасов.
11 сен 19, 15:52    [21968634]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Да - отгрузки нет. Изделие монтируется на еще большее изделие заказчика нашими силами.
11 сен 19, 15:53    [21968635]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ldfanate
Member

Откуда:
Сообщений: 129
ну значит в ворота завода лязгая гусеницами вползает Платформа (т.е. на подотчёт вашей фирме сторонний заказчик выдаёт имущество с определённой стоимостью), а выползает с завода Платформа+Изделие (уже с другой стоимостью).
Всёравно оборот основных средств, товаров (Изделий) и работ-услуг (в т.ч. монтаж Изделия на башенный погон) на предприятии должен присутствовать.
11 сен 19, 16:04    [21968644]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ldfanate
Member

Откуда:
Сообщений: 129
и наверное, номенклатура готовых Изделий, и Спецификаций к ним будет ещё и соотноситься с номенклатурой Платформ. Т.е. будут частичные и полные аналоги взаимозаменяемости.
потому что голдовую башню от абрамса не на каждое рено вкрячишь
11 сен 19, 16:08    [21968650]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Stanislav P
Member

Откуда: Сочи
Сообщений: 82
Serg197311
code OWN sernn codever qt
151 145 1 59 1
152 146 1 60 1
153 146 1 61 1

Типа так
Code - код текущей записи в MAIN1
OWN - код вышестоящей записи из MAIN1
sernn - код изделия
codever - код детали(сборки) из основного каталога MAIN
qt - количество

Есть большое подозрение, что Own или sernn или codever лишнее поле в таблице MAIN1
Так как в таблице MAIN1 должно хватить четырёх полей для описания всех деталей входящих в составное изделие.
11 сен 19, 17:43    [21968741]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ldfanate
ну значит в ворота завода лязгая гусеницами вползает Платформа (т.е. на подотчёт вашей фирме сторонний заказчик выдаёт имущество с определённой стоимостью), а выползает с завода Платформа+Изделие (уже с другой стоимостью)..

)))) Ну почти так))))
ldfanate
Всёравно оборот основных средств, товаров (Изделий) и работ-услуг (в т.ч. монтаж Изделия на башенный погон) на предприятии должен присутствовать.

Да кто ж говорит что этого нет? Я говорю что продажники для этого не нужны:))
12 сен 19, 06:38    [21969066]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Stanislav P
Есть большое подозрение, что Own или sernn или codever лишнее поле в таблице MAIN1
Так как в таблице MAIN1 должно хватить четырёх полей для описания всех деталей входящих в составное изделие.

Да? А какое?
OWN - указывает к какой вышестоящей сборке принадлежит эта запись(деталь, подсборка). Если его убрать - теряется структура изделия, невозможно построить дерево вхождений.
sernn - указывает к какому именно изделию относится эта деталь/сборка
Конечно, можно вместо этого поля привязать еще одну табличку, в которой будут записи с указанием номера ИЗДЕЛИЯ только для головной сборки. Но это сильно затормозит процесс выборки, построения дерева и обработки статистики, а экономия места в базе совсем небольшая.Так что я решил поступить так.
codever - это указание на саму деталь /сборку. Без этого вообще никак ИМХО.
qt - количество этой детали в вышестоящей сборке. как без него - тоже не понимаю
Если сможете помочь оптимизировать - буду очень благодарен.
12 сен 19, 06:47    [21969067]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ldfanate
и наверное, номенклатура готовых Изделий, и Спецификаций к ним будет ещё и соотноситься с номенклатурой Платформ. Т.е. будут частичные и полные аналоги взаимозаменяемости.

Да в том то и особенность. Практически каждое ИЗДЕЛИЕ - индивидуально, его спецификация уникальна.
взаимозаменяемы/применяемы на разных Платформах только некоторые компоненты (сборочные единицы).
12 сен 19, 06:51    [21969068]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ldfanate
Member

Откуда:
Сообщений: 129
автор
Практически каждое ИЗДЕЛИЕ - индивидуально, его спецификация уникальна.
взаимозаменяемы/применяемы на разных Платформах только некоторые компоненты


Бедные интенданты, как потом тыловое обеспечение запчастями обеспечивать в условиях войны?

Ну вобщем, предложение разузловывать на полную глубину все спецификации.
12 сен 19, 07:04    [21969069]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ldfanate
автор
Практически каждое ИЗДЕЛИЕ - индивидуально, его спецификация уникальна.
взаимозаменяемы/применяемы на разных Платформах только некоторые компоненты


Бедные интенданты, как потом тыловое обеспечение запчастями обеспечивать в условиях войны?.

На всякий случай) дабы чего не случилось) ИЗДЕЛИЕ по сути - комплект мебели))

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

Ну так сейчас и делается, и по всей видимости так и будет делаться...
12 сен 19, 07:26    [21969074]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4592
Serg197311
qt - количество этой детали в вышестоящей сборке

неужели у вас все детали входят СТРОГО в свою сборку, т.е. нет деталей, которые входят в несколько сборок/подсборок(хотя бы гайки и подобное)
12 сен 19, 09:01    [21969103]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ПЕНСИОНЕРКА
неужели у вас все детали входят СТРОГО в свою сборку, т.е. нет деталей, которые входят в несколько сборок/подсборок(хотя бы гайки и подобное)

Да есть конечно! полно! А что вызывает сомнения?
Есть несколько записей с разным количеством в узле(qt) и одинаковым кодом ИЗДЕЛИЯ(sernn) и кодом детали codever
но отличающихся OWN - кодом вышестоящей сборки.
12 сен 19, 09:04    [21969108]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4592
Serg197311
его спецификация уникальна.
взаимозаменяемы/применяемы на разных Платформах только некоторые компоненты (сборочные единицы)

как у вас прописываются эти повторяющиеся единицы

например сборка1 состоит из (подсборки1, пс2, д11,д12,д13)
и она входит в изделия и1,и3,и5

как в этом случае просчитывается количество пс2 или д12(ваша функция это не обеспечивает, если конечно вы не повторяете описание (подсборки1, пс2, д11,д12,д13) в каждом изделии с другими номерами code/own
12 сен 19, 09:08    [21969113]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ПЕНСИОНЕРКА
если конечно вы не повторяете описание (подсборки1, пс2, д11,д12,д13) в каждом изделии с другими номерами code/own

Да, повторяю для каждого изделия с другими code/own. И не вижу другого способа. Неизменных сборочных единиц(структура которых постоянна) 1 из 10. Все остальное может поменяться как угодно. Производство по сути не серийное, опытное. Поэтому и систему советскую, что отлично работала на серийных производствах, применять не хочется....
12 сен 19, 09:13    [21969115]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4592
Serg197311
ПЕНСИОНЕРКА
если конечно вы не повторяете описание (подсборки1, пс2, д11,д12,д13) в каждом изделии с другими номерами code/own

Да, повторяю для каждого изделия с другими code/own. И не вижу другого способа. Неизменных сборочных единиц(структура которых постоянна) 1 из 10. Все остальное может поменяться как угодно. Производство по сути не серийное, опытное. Поэтому и систему советскую, что отлично работала на серийных производствах, применять не хочется....


короче, у вас имеются многие тысячи деталей, многие из них вариантны по исполнению

и из них вы строите как в детском конструкторе некое сооружение, подбирая в проблемных местах решение, применяя ранее сделанные детали или добавляя новые, если размеры СТАРЫХ деталей не вписываются в размеры
12 сен 19, 09:37    [21969128]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
ПЕНСИОНЕРКА

короче, у вас имеются многие тысячи деталей, многие из них вариантны по исполнению

и из них вы строите как в детском конструкторе некое сооружение, подбирая в проблемных местах решение, применяя ранее сделанные детали или добавляя новые, если размеры СТАРЫХ деталей не вписываются в размеры

Так.... Это реальность, данная мне в ощущении)
12 сен 19, 09:48    [21969136]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Stanislav P
Member

Откуда: Сочи
Сообщений: 82
Serg197311,

Смотри, у тебя есть единый каталог (таблица CATALOG) номенклатурных единиц из которых собирается готовое изделие. В этот каталог входят такие изделия как болты и гайки, они неделимые. Так же есть изделия, которые собираются из других изделий, как неделимых так и таких-же сборных, они так-же входят в каталог. Для того, чтобы знать состав составного изделия нам нужна таблица с детализацией (DETAILS).
Чтобы такое реализовать минимально нужна такая структура:
Таблица CATALOG:
cat_id - уникальный код изделия (первичный ключ)
cat_name - наименование изделия
cat_type - тип изделия (составное изделие или простое)
Таблица DETAILS:
det_id - уникальный код строки (первичный ключ) ' Можно и без этого поля обойтись взяв за первичный ключ связку owner_id + det_id это зависит от того, веришь ли ты в составные ключи или считаешь их дьявольским изобретением :)
owner_id - код (cat_id) составного изделия из таблицы CATALOG
det_id - код (cat_id) изделия из таблицы CATALOG 'det_id так же может ссылаться на составное изделие
quantity - количество det_id входящих в состав owner_id

Я не делал поля для указания вышестоящей сборки, для того, чтобы построить дерево оно не обязательно - достаточно пройтись запросом в котором указать WHERE cat_type="составное" и получить список всех составных изделий входящих в это конкретное составное изделие и их состав.

При такой структуре делать копию составного изделия просто для твоего первого варианта, когда каждое составное изделие уникальное. И так же просто его использовать и во втором варианте, когда нужна будет версионность составных изделий. И, если вдруг такое случится, будет проще повторно использовать одно и то же составное изделие.
Да, запрос на выборку станет сложнее и нужно будет чуть больше подумать над функцией построения дерева.
12 сен 19, 10:19    [21969164]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
я как раз колеблюсь между этим путем и отсутствием details .
Пока больше склоняюсь к тому, что бы хранить структуру сборки в таблице где хранится вся структура изделия.... выше я детально описывал.....
12 сен 19, 10:23    [21969172]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Stanislav P
Member

Откуда: Сочи
Сообщений: 82
Serg197311
Пока больше склоняюсь к тому, что бы хранить структуру сборки в таблице где хранится вся структура изделия.... выше я детально описывал.....

Ох, чую как ты себе геморрой обеспечиваешь такой организацией БД.
12 сен 19, 10:46    [21969211]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Stanislav P

Ох, чую как ты себе геморрой обеспечиваешь такой организацией БД.

Вот я и пытаюсь сообразить - какой именно?
12 сен 19, 10:47    [21969214]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Лапух
Member

Откуда: Стойбище № 7
Сообщений: 880
Serg197311
....Толцытеся.... и отворится вам!....

Моя твоя не понимай.
Какая диалекта языка твоя говорить?
13 сен 19, 17:01    [21970573]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Stanislav P
Member

Откуда: Сочи
Сообщений: 82
Serg197311
Вот я и пытаюсь сообразить - какой именно?

Запихивая в одну таблицу состав конечного изделия и состав составного изделия ты лишаешь себя гибкости. Завтра тебе предложат подключить к системе ещё кладовщиков, сметчиков и тогда тебе придётся переделывать архитектуру БД, а это геморрой.
13 сен 19, 17:32    [21970610]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Лапух
Member

Откуда: Стойбище № 7
Сообщений: 880
Stanislav P
...и тогда тебе придётся переделывать архитектуру БД, а это геморрой...

А я всегда пропагандирую, что БД, даже с самыми невероятными вероятностями, должна быть как можно более - Универсальной[u][/u], дабы какой то там геморой не доставал.
Просто добавил неверояное значение и уже ни чего не болит в попке. Картинка с другого сайта.
Сиди, кури как орёль на вершине Кавказа. Картинка с другого сайта.
13 сен 19, 17:50    [21970617]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Лапух
Serg197311
....Толцытеся.... и отворится вам!....

Моя твоя не понимай.
Какая диалекта языка твоя говорить?

Старославянский:)
сегодня, 06:34    [21971306]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Stanislav P
Запихивая в одну таблицу состав конечного изделия и состав составного изделия ты лишаешь себя гибкости. .
Согласен.

Stanislav P
Завтра тебе предложат подключить к системе ещё кладовщиков, сметчиков и тогда тебе придётся переделывать архитектуру БД, а это геморрой.
не, это не предложат - этим 1С будет заниматься. Но..... действительно хрен его знает что еще случиться.... И поэтому - иду по первому пути - запрещаю вносить изменения в сборку. Но!!!!таблицу details таки сделаю, на всякий случай)
сегодня, 06:38    [21971307]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Serg197311
И поэтому - иду по первому пути - запрещаю вносить изменения в сборку. Но!!!!таблицу details таки сделаю, на всякий случай)

Косяг блин....
гружу сборку например с 4 уровнями вложенности......
Уровень 1 - деталь1
уровень 2 - даталь2, деталь3
И есть деталь4 уровня 3(состоит из деталь5,деталь6 уровня 4), которая входит в деталь2 и деталь3 в разных количествах....
при загрузке деталей 5 и 6 - ключи дерева задваиваются..... записи то в details одни и теже....
сегодня, 13:32    [21971558]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 518
Итого для получения полной структуры сборки из details придется делать еще одну, временную, таблицу со своими уникальными кодами..... так что ли?
сегодня, 13:40    [21971565]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3      [все]
Все форумы / Microsoft Access Ответить