My Visual Database — Сохранение данных в таблицы

Re: Сохранение данных в таблицы

null@example.com (chaoba) — Thu, 10 Jan 2019 06:22:27 +0000

Derek, thank you very mach !

Re: Сохранение данных в таблицы

null@example.com (sibprogsistem) — Wed, 09 Jan 2019 00:19:12 +0000

derek wrote:

Привет снова, Chaoba,
Избыточные данные обычно относятся к данным об одном и том же субъекте, которые хранятся более одного раза, а не к данным, относящимся к разным субъектам.
Пожалуйста, посмотрите на диаграмму. Верхняя часть диаграммы показывает, как данные хранятся в плоском файле - красные прямоугольники показывают все данные, которые являются избыточными.
Когда вы создаете реляционную базу данных, вы удаляете избыточность, создавая связанные таблицы и связывая эти таблицы с тем, что называется «внешним ключом». Посмотрите на синие прямоугольники - «таблица строк счета» связана с «таблицей заголовка счета» его внешним ключом заголовка счета. «Таблица заголовков счетов» связана с «таблицей счетов» внешним ключом таблицы счетов. Ничего не повторяется
MVD создает все это автоматически - все, что вам нужно сделать, это создать ссылку в вашей структуре данных.
Наконец, посмотрите на зеленые коробки; это не избыточные данные, просто один и тот же товар (принтер) был куплен по двум разным счетам двумя разными покупателями.
Я надеюсь, что это не делает вещи более запутанными! Но важно получить правильную структуру данных. и когда это, MVD очень прост в использовании.
Regards,
Derek.

Re: Сохранение данных в таблицы

null@example.com (derek) — Tue, 08 Jan 2019 21:53:36 +0000

Привет снова, Chaoba,
Избыточные данные обычно относятся к данным об одном и том же субъекте, которые хранятся более одного раза, а не к данным, относящимся к разным субъектам.
Пожалуйста, посмотрите на диаграмму. Верхняя часть диаграммы показывает, как данные хранятся в плоском файле - красные прямоугольники показывают все данные, которые являются избыточными.
Когда вы создаете реляционную базу данных, вы удаляете избыточность, создавая связанные таблицы и связывая эти таблицы с тем, что называется «внешним ключом». Посмотрите на синие прямоугольники - «таблица строк счета» связана с «таблицей заголовка счета» его внешним ключом заголовка счета. «Таблица заголовков счетов» связана с «таблицей счетов» внешним ключом таблицы счетов. Ничего не повторяется
MVD создает все это автоматически - все, что вам нужно сделать, это создать ссылку в вашей структуре данных.
Наконец, посмотрите на зеленые коробки; это не избыточные данные, просто один и тот же товар (принтер) был куплен по двум разным счетам двумя разными покупателями.
Я надеюсь, что это не делает вещи более запутанными! Но важно получить правильную структуру данных. и когда это, MVD очень прост в использовании.
Regards,
Derek.
.
Redundant data typically refers to data about the same subject that is held more than once, not data that is held against different subjects.
Please have a look at the diagram. The top of the diagram shows how data is held in a flat file - the red boxes show all the data that is redundant.
When you create a relational database, you remove the redundancy by creating related tables and linking those tables with what is called 'a foreign key'. Look at the blue boxes - the 'invoice line table' is related to the 'invoice header table' by its invoice header foreign key. The 'invoice header table' is related to the 'account table' by its account table foreign key. Nothing is repeated
MVD creates all this automatically - all you need to do is create a link in your data structure.
Finally, look at the green boxes; this is not redundant data - it is simply that the same item (a printer) has been bought on 2 different invoices by 2 different customers.
I hope this doesn't make things more confusing! But it is important to get your data structure correct. and when it is, MVD is very straightforward to use.

Re: Сохранение данных в таблицы

null@example.com (chaoba) — Tue, 08 Jan 2019 14:24:46 +0000

Спасибо!

Re: Сохранение данных в таблицы

null@example.com (k245) — Tue, 08 Jan 2019 14:13:16 +0000

Согласен с Дереком - не стоит делать отдельные таблицы для фамилии и имени. Даже в крупных информационных системах эти данные хранятся в одной таблице, так как с вероятностью 99.9% вам никогда не понадобится какая-либо аналитика по фамилии или имени. Обычно данные поля являются текстовыми свойствами сущности "Субъект".

Re: Сохранение данных в таблицы

null@example.com (chaoba) — Tue, 08 Jan 2019 06:49:38 +0000

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

Re: Сохранение данных в таблицы

null@example.com (derek) — Mon, 07 Jan 2019 19:10:36 +0000

Привет Chaoba,
Может быть, я неправильно понимаю ваш вопрос, но я не понимаю, как поможет создание 2 дополнительных таблиц, которые содержат только 1 поле (имя) и 1 поле (фамилия)? Кроме того, с точки зрения базы данных, это не очень хороший дизайн.
Может ли ваша проблема (если я правильно понимаю) не быть решена простым использованием полей поиска для фильтрации вашей таблицы?
Пожалуйста, посмотрите на пример, где я использую только 1 таблицу. В поле поиска вы можете ввести что угодно - имя, фамилию, дату, телефон и т. Д. - и в любой комбинации. Например, поиск «John», поиск «Smith», поиск «John Smith», поиск «200», поиск «.org» и т. Д. И т. Д. Извините - все данные на английском
Derek.
.
Maybe I misunderstand your question, but I do not understand how the creation of 2 additional tables that contain only 1 field (name) and 1 field (last name) will help? In addition, from a database point of view, this is not a very good design.
Can your problem (if I understand correctly) not be solved by simply using search fields to filter your table?
Please look at the example where I use only 1 table. In the search field, you can enter anything - first name, last name, date, phone number, etc. - and in any combination. For example, the search for "John", the search for "Smith", the search for "John Smith", the search for "200", the search for ".org", etc.. Etc. Sorry - all data in English.

Re: Сохранение данных в таблицы

null@example.com (sibprogsistem) — Mon, 07 Jan 2019 15:51:20 +0000

вам нужны таблицы
1. Имя
2. Фамили
3. Инная информация...

есть 2-варианта
1. с начало нужно создать запись в таблице ФИО
потом используя компонент комбобокс создать запись во вторую таблицу.. где комбобокс будет играть роль Ключа записи

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

вот пример связи

Сохранение данных в таблицы

null@example.com (chaoba) — Mon, 07 Jan 2019 12:57:54 +0000

Вопрос новичка.
Т.к. бывает много людей с одинаковыми фамилиями и именами создал таблицу Имя, Фамилия и 3-я где будут все остальные данные.
Для сохранения даннык к кнопке привязывается таблица, в которую эти данные необходимо внести. Значит одна кнопка может внести данные только в одну таблицу.
В связи с этим вижу 2 возможных решения.
1 На форме установить 3 кнопки записи по одной на каждую таблицу, что для пользователя не очень удобно.
2. Поставить одну кнопку и привязать к ней скрипт, где описать запись в эти таблицы из соответсвующих полей.

Я правильно понимаю?