Что-то, мне кажется, мой вопрос уберут из списка.
Я все стесняюсь, задавать вопроси, так как начинающий в работе с базами, и боюсь, как бы вопрос не получился, слишком простим и слишком глупим, но когда по форуму встречаются, вопроси которые и мне кажется легкими, то рискну:
В простом изложении задача такая:
Ест фирма, у фирмы магазины. С каждого собирается повседневные отчеты о продажах. В программе можно увидеть остатки в каждом магазине, остатки в целом, перечень всех товаров и т.д. Все тривиально.
Раньше, у меня это било сделано в Excel-e. На свою голову, начал все делать в гибриде с Access.
Чем больше узнаю о базах, тем больше возможностей обнаруживаю и уже четвертый раз меняю стратегию решения задачи, в чем и нужна консультация знающих людей.
Я имею Таб1 для кодов и наименовании товара, Таб2 для кодов магазинов, Таб3 для кодов поставщиков, кое какие таблицы еще и n количество таблиц соответствующих магазинов и поставщиков + таблица склада.
Каждодневные отчеты, при вводе, прямо воздействует на соответствующие таблицы. Мне интересно ваше мнение о такой постройке решения, также мнение о таком распределении данных по таблицам. Знаю, где-то ест теория про все это, но прочитанное в одном или нескольких местах это одно, а опит, другое.
Ну, очень прощу!

Извиняюсь! Перенесите.

Если у вас для каждого магазина была своя страничка в ёкселе, то в реляционых БД такой подход категорически не приветствуется.Как раз, вы правильно уловили. Я чувствую, что я не одолеваю Excel- овский подход решения этой задачи.

Если воспримете, небольшой совет:Не то чтобы восприму, проглочу.

В Excel-е таблицы хранились в отдельных файлах (Write Print Input sequential file сами чувствуете, какой ужас). Пока магазинов било мало думал так отделаюсь. Но уже дело дошло до 60 торговых точек и в среднем 800 записей в день!!!
Один и главный совет я уже поучил от вас
Если у вас для каждого магазина была своя страничка в ёкселе, то в реляционых БД такой подход категорически не приветствуется.

Сразу почувствовал гибкость такой таблицы, если, конечно, правильно понял, но ест вопрос:
Что заносить в записи этой таблицы, повседневную информацию о продажах или лучше прямо результат изменении в количествах?
Первое по идее, лучше имеется вся история в руках для любой обработки, но размер таблицы пугает, количество наименовании товара превышает 3000, всякие мелкие принадлежности. (Т.е. Если я правильно понял, поля тоже будут около 3000).

To u4x96

Я писал что, несколько раз начинал заново все делать.
Как раз, этот вариант тоже собирался делать, но отверг.
В принципе, точно это сделано и в этот момент, только для страховки (в причину нехватки знания) и быстроты результатов запроса, добавлены таблицы магазинов и поставщиков, в которых сразу заношу изменения, при вводе новых данных о движении в таблицу 5. Что, чувствую, вообще не совместимо с принципами построения баз данных..
Кто ответили, все напрочь отвергают отдельные таблицы для магазинов и поставщиков. Понял но, прошу посоветовать:

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

Добавлю еще, что таблица Артикли (Код, Название, ...), содержит еще поля “Группа”, “Подгруппа”. Которые тоже участвуют в условиях выборки.

.

To Программист-Любитель

Из Excel оставил только интерфейс, ввод данных и управляющие элементы. В основном все делаю запросами. Все базы в mdb.
Ваш ответ воодушевляет.


To u4x96
Зачем, какие изменения, при вводе новых данных достаточно ввести их таблицы Документы и Движения.Безусловно, достаточно. Исходя из следующего:
Лечится еще одной таблицей "Остаток" и тригерами на "Движение" которые будут ее обхавлять.Я правильно понял?

Программист-Любитель Но! Если у вас стоит задача поддержания а работающем состоянии всех бизнес-процедур во время переходного периода, то ... можно только искренне сочуствовать - задача очень трудная ...Все что в данный момент работает, трещит от нагрузки. Задача стоит чуть “полегче”: Приготовить, запихнуть все данные на тот момент в виде остатков в каждом объекте. Все что до этого момента, отложить. Создать Новую программу, скинуть “отложенное” туда, привести в форму нужного БД, состыковать с рабочим. Вот, это все. Если, внятно передал.

Вопрос: Если еще в силе: Программист-Любитель На такого рода объеме данных, как у вас, решение на Аксессе должно работать вполне удовлетвортельно, а на SQL'e - так вообще замечательно. то посоветуете или нет, вообще исключить следующую таблицу, u4x96 Лечится еще одной таблицей "Остаток" и тригерами на "Движение" которые будут ее обхавлять которая в принципе только для быстрого отчета по объектам. Или нет?

И чтоб не надоедать, последний вопрос:
Раз, база mdb а не SQL сервер, что вы можете посоветовать, если при начале работы будет формироваться временная база с таблицами или таблицей остатков (только во время сеанса), в таком режиме самый надежный “тригер” это то, что ввод данных происходит с Excel и все программное управление под рукой (конечно не совсем изящно, или совсем не изящно, но может, это ест вариант?)
А ждать придется только в начале, как будто приложение загружается.

Ну, все, с чего-то нужно начинать.

Спасибо за терпение и добродетельность!

.

Можете объяснить, почему?
Вы поймите, я здесь ничего не могу утверждать, я слушаю других. Вы дали идею и ушли. А для его реализации нужны вещи (MSSQL, c тригерами). А база mdb, я ваяю на VB, все било сделано в Excel-e, базы заносились прямой записью в файлы на диске. Все это вам не о чем не говорит? В частности: Я уверен, что для вас и для всех, кто хорошо знают ДБ это смешная задача, это, наверное 2+2 для этой сферы, а я не знаю в нем почти ничего. Специально начал работать в Access, которую ненавидел (здесь поставил бы “смаилчик”, но невозможно) а сейчас очень люблю (здесь тоже), специально изучил, на каком-то уровне, азы SQL языка, читаю стати Тенцера чтобы хоть в чем-то разобраться. Какой MSSQL? Да вы что? Пока я дорасту до этого, меня вышвырнут отсюда. Для таких объемов, какие ожидаются, я это сделаю на родном VB, и в двое быстрее, но знаю, что для этого существует специально для него созданная теория и специально, для его разработки созданные вещи.

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

Вопрос: Что делает это таблица, про которую вы говорите? Убыстряет выборку, да? Или я опять не понял вас?

1. Таблица "Магазины" (Код, Название, ...)
2. Поставщики (Код, Название, ...)
3. Артикли (Код, Название, ...), ессли ведется партийный учет КодПартии
4. Документы (Код, Дата,КодМагазина, КодПоставщика, Тип Поставка/OтчетПродаж, ... )
5. Движения (Ко, КодДокумента, КодТовара, Колво, Сумма, СтавкаНДС и здесь ничего больше липить не надо) для Поставок Колво, Сумма полозительное, для OтчетПродаж отрицательное

Эта част вашего совета, как я писал выше, у меня так и сделана, чему искренно радуюсь, потому что она, в принципе совпало с мнением специалиста.