@VinniPuh

Всем доброго и удачного дня!
Пытаюсь создать БД, в которой при поступлении Товара и выборе - Места его размещения на Складе, в данной записи в табличке - СкладМесто у логического элемента - ФлЗанятоМ автоматом проставлялось значение - Да, чтоб потом его ужо нельзя было выбрать из списка при размещении другого товара (т. к. стоит в условие отбора - Нет).
Уж и в источнике записей вставлял табличку - СкладМесто, но получается ерунда, вручную ставлю галочку, а она проставляется сразу у нескольких записей.
Как это сделать, чейта ни как не допетрю, почти целый день бъюсь , не получается.
Может есть какое простое решение, подскажите пожалуйста.
Заранее благодарен - ПУХ.

Вложения

СкладРазмещение-001.rar (128.2 Кб, 78 просмотров)

0

@Вячеслав Я

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

0

@Серж_87

0

@VinniPuh

mobile - Еще раз Спасибо. Вы и взаправду Всевидящий.
Да уж, это называется - Поспешишь и будешь невнимательным - Сутки промучаешся, а толку не будет. .
Такое со мной практически первый раз Обычно если связью не в туда попадешь, практически сразу замечаешь, а тут наверное глаз замылился. :black_eye.:

0

@VinniPuh

Всем доброго и удачного дня!
В процессе ваяния БД залетело несколько мыслев в голову, и вскочил вопрос, а не лучше ли будет если:
2. Вместо создания нескольких таблиц и форм типа:
Поставщики, Клиенты, Сотрудники, Посредники
Создать 1 общую таблицу и 1 форму, а разграничать и отличать их по Типу контакта.
3. Так же есть мысля, таблицы - Приход и Расход объединить в одну с полем - Тип Операции:
Приход, Расход, Списание, Перемещение (с одного склада на другой).
Прошу совета, стоит ли так делать и если кто эксперементировал по данным вопросам, подскажите Плюсы и Минусы какие есть, а то может и подводные камешки присутствуют?
Заранее благодарен - ПУХ.

Добавлено через 44 минуты

0

@zikmik

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

1

@VinniPuh

Не совсем понял о чём ВЫ, но за внимание к моей проблемме ставлю +1.

0

@Вячеслав Я

kmv-puh, про клиентов ни чего не скажу, надо экспериментировать. Про склады могу сказать: если рассматривать в разрезе одного склада, то можно обойтись и одной таблицей с полями Приход и Расход. Если же у Вас несколько складов, то лучше в обязательном порядке принять ТМЦ на один из складов (в одной таблице). В ней у него будет свой Номер_прихода и Количество_прихода. И уже со своим Номером_прихода, в другой таблице, это ТМЦ может переходить по складам или списываться в производство (хоть частями, хоть полностью).

1

@zikmik

это поводу" Так же есть мысля, таблицы - Приход и Расход объединить в одну с полем - Тип Операции:
Приход, Расход, Списание, Перемещение (с одного склада на другой).
Прошу совета, стоит ли так делать и если кто эксперементировал по данным вопросам, подскажите Плюсы и Минусы какие есть, а то может и подводные камешки " -отвечаю, что так обычно и делают, а если ваша база должна работать, а не для того ,чтобы показать преподавателю, то следует на физическом уровне ее как следует продумать. по типу поступил товар, что при этом должно происходить и в каких таблицах происходить изменения?

0

@VinniPuh

zikmik - Ну так я и думаю, возникли вопросы и сомнения, Вот я и сумлеваюсь - Вдруг переделывать много чего придется, а не сильно охота.
К примеру на моем примере, можете показать как должны выглядеть правильные таблицы и связи?

0

@Вячеслав Я

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

1

@VinniPuh

Вячеслав Я - Во-Во-Во, я тоже сумлеваюсь и хотелось бы услышавть МНЕНИЕ МНОГИХ и ОСОБЕННО УМУДРЕННЫХ ЖИЗНЕННЫХ ОПЫТОМ, т. к. на форуме просмотрел множество идентичных тем, и в 80 % это 2, а не 1 таблица.
Сделать, а потом убедившись, что это было не - Камильфо - м переделать не проблемма, но довольно много времени уйдет впустую, типа не ЛЯ .

Добавлено через 37 минут
Если честно, то впадаю в ПАНИКУ и УНЫНИЕ, - Почему нет ни одной рекомендации и Совета от таких ОБЩЕПРИЗНАННЫХ МЭТРОВ В СФЕРЕ типа - СКЛАД, как :
mobile
ltv_1953
Agapov_stas,
да и многих других Профессоров Аксика
Печально , что нет помощи от МНОГОМУДРЫХ и ни одну собаку съевших по данному вопросу ПРОФИ..
Чем же они таким важным заняты. что на форуме их НЕ МА?

0

@zikmik

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

0

@VinniPuh

Я не говорил. что 1 форму, я говорю про 1 таблицу. по которой можно сделать хоть сколько нужно Форм.
Ну в принципе, это вроде бы элементарно делается запросами, на крайняк вывести просмотр Списком или ПолемСоСписком, это я умею.
Ну в принципе Склад еще полностью Не вижу, но представляю это Так:
Заказываю товар (т. к. Имеется тенденция к множественному потреблению заказчиками)
Приходит товар по определенной цене, в количестве,
Размещаю на определенном складе, на определенном месте. Жранится.
Приходит Заявка из магазина или Даже лично САМ Клиент или Покупатель, Спрашивает - А Есть ли.
Есть. Берете - Беру.
Делаю накрутку с учетом МЕНЕ доставки, Хранения 30 мин. + за работу кладовщику и сторожу - Выдаю за определенную сумму - Все Довольны
Примерно так.

0

@Серж_87

Так и должно быть во всех БД. Добавить доп. поле в таблицы ("П" или "Р") для идентификации. Минусов нет Это тоже правильно. Но сотрудников мне кажется в другую таблицу нужно.

0

@zikmik

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

0

@VinniPuh

emenem97 - Да, я тоже к этову больше склоняюсь, т. к. про Сотрудников своей организации нужно больше знать чем про других, т. к. иногда нужно знать для обеспечения социальных гарантий - Возраст, Пол, Зарплату, Сколько Детей, да и полно всего другого разного.
это конечно в идеале, а я только учусь и эксперементирую, но в идеале хотся создать идеальную БД для любимого АКСИКА, чтоб даже Мускулы позавидовали.

0

@Серж_87

kmv-puh, совет - я бы не стал заморачиваться и пытаться в аксесе сделать базу склада. Аксес не подходит для таких задач. Любой пользовтель сломает ее за 5 секунд. Нет распределение ролей и прав (можно но очень тяжело, не стоит этого). нет тригеров даже. Еще можно 10 причин привести по которым не стоит. Время тратишь только Идеальную базу чтобы сделать, повторюсь, очень очень очень много времени и сил нужно

0

@VinniPuh

А я разве хоть одним словом обмолвился, что вы новичок или не спец, для меня лично все равны (Естественно кроме тех, кто мене не менее 1000 раз реально на примере или путным советом помог).
Себя не смотря на довольно высокий рейтинг на форуме не считаю спецом, просто часто успевал первым подсказать как объединить 2 или 3 поля в запросе в одно. , Ну и Погранцы естественно часто Плюсики ставят.

0

@zikmik

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

0

@VinniPuh

Ну ваабщето я спросил и попросил совета, как его - Склад - лучше и как можно более компактнее сделать.
Если у вас есть реальные примеры, то выкладывайте, желательно в Аксике 2000, если просто слова, то лично мене и моей деревне это не понятно, т. к. Академиев не заканчивали к сожалению.

0