BG Development


Страници: (2) [1] 2   ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> Полета с миксирани типове
Delegate
Публикувано на: 04-03-2019, 19:23
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1722
Регистриран на: 30.05.09



Трябва да дигитализирам една "регистратура" от времето на Вълко Червенков. Иде реч за сравнително проста регистрация на входящи/изходящи документи, която към настоящия момент се води на някакви дневници/големи книги с графички/.
Лелките, като са полъвали хартиените "носители" ползват някаква архаична конвенция за всякакви номера от сорта на "ВХ.11/413/2007", което в случая е входящ номер от 2007 г. с пореден номер 413 от регистър 11.
Сега, при съставянето на електронния регистър възниква проблема с множествените типове данни в това "съставно поле", има дати, има поредни и уникални номера, които трябва да се инкрементират автоматично (413) и чист текст "ВХ." Тази челочислена интеджер част (413) даже трябва служи, като индекс към други записи.
Необходимо е именуването, изгледа и конвенцията да се запази, поне във фронт енда, отзад в базата данни имам свобода да ги раздробявам нещата, както сметна за добре.

Имам няколко идеи разбира се, но искам да чуя евентуално ако има хитри решения или да ги раздробявам на отделни полета, да ги следя всичките за уникалност (хеш?) и да ги конкатенирам после при визуализацията ?

По идея ще се ползва MySQL 5,7

Това мнение е било редактирано от Delegate на 04-03-2019, 19:27
PMEmail Poster
Top
Gamma Goblin
Публикувано на: 04-03-2019, 20:14
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2106
Регистриран на: 21.02.18



Защо не ги пазиш като едно varchar поле ?


--------------------
https://www.rust-lang.org/
---
Недобросъвестните оратори се опитват да изкарат лошото добро.
---
PMEmail PosterUsers Website
Top
thrawn
Публикувано на: 04-03-2019, 20:38
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2108
Регистриран на: 17.01.17



Ми запази я де. Какъв е проблема?
Нормализираш съставното поле и получаваш три полета: година, регистър и пореден номер (тука автоматично получаваш бонус, че можеш да ползваш партишъни я по година, я по регистър, я и по двете). Префиксът вх. Предполагам е константа, та е безсмислено да го буташ в базата данни.

За уникалност не ти трябва ти да ги следиш - това е работа на базата данни. Достатъчно е да си декларираш трите полета като съставен, може би, дори първичен ключ.

А защо ще стартирате проект с толкова стара БД вие си знаете...

Това мнение е било редактирано от thrawn на 04-03-2019, 20:40
PMEmail Poster
Top
Delegate
Публикувано на: 04-03-2019, 20:48
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1722
Регистриран на: 30.05.09



QUOTE ("Gamma Goblin")
Защо не ги пазиш като едно varchar поле ?


Не ми се ще да парсвам текстове, да инкрементирам чисълцата вътре и после пак да ги слепвам. Пък и искам да филтрирам по съответните полета година/номер но да не е с %LIKE%. Чисълцето посредата май ще трябва по-късно да играе и индекс към друга таблица и не искам да се забивам в тесктови полета, дето да държат "всичко"

@thrawn:
Да, това смятам да направя, въпреки, че лелките ще пискат, че преди са попълвали една графа(без да се замислят, че тя е съдържала всички тия неща), а сега 4 или 5 (номера горе е само примерен, има още атрибутчета)
PMEmail Poster
Top
thrawn
Публикувано на: 04-03-2019, 20:54
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2108
Регистриран на: 17.01.17



Ми ти пак им го остави да си го въвеждат на куп, щом така са свикнали. Но като цяло, ключовете не се въвеждат от лелките. Ключовете ги генерира системата и ги изплюва на лелката, която ги пише в разни листчета. Точно това е идеята на тоя входящ номер.

Ти си направи базата данни както трябва, пък потребителския интерфейс винаги можеш да го модифицираш.

Това мнение е било редактирано от thrawn на 04-03-2019, 20:56
PMEmail Poster
Top
Delegate
Публикувано на: 06-03-2019, 20:39
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1722
Регистриран на: 30.05.09



Да, ясно е за ключовете. Те се генерират и визуализират без възможност за едит.
Аз си герерирам UI-я от базата и типовете на полетата така, че да мога динамично да добавям/премахвам/променям кутийки за въвеждане без да прекомпилирам и т.н. така, че на очкавам да има драми там.
Относно стария енджин на мъсяла - има и други дипендансита и легаси неща.
PMEmail Poster
Top
Delegate
Публикувано на: 09-03-2019, 19:59
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1722
Регистриран на: 30.05.09



Малко по-различен казус.
Имам таблица с хора и техните атрибути, имена, адреси, телефони и др.
Как би трябвало да изглежда едно просто и неограничаващо решение, ако искам да имам следната функционалност:
Всяка персона, може да бъде състезател, може да бъде капитан на отбора, както и роднина на предишните 2 вида. Тоест имам 3 типа персони
1. captain
2. player
3. relative

капитана и играчите принадлежат на един отбор( team), дефиниран за всеки конкретен мач, а всеки team има участия(match) (дата, място, описание). За всеки мач тиймовете може да са различни, съставени от различни играчи и капитани.

Всеки капитан и играч има 0 или повече роднини(relatives), играчите помежду си също може да са роднини, както и с капитана. Капитаните на различи отбори също може да са роднини. Роднинсите връзки между роднини, които не са нито играчи, нито капитани не е важна.

Понеже всички типове са в крайна сметка хора, искам по възможност да го направя с една таблица със съответните атрибути - имена, адреси, телефони и др.

Предполагам само-рефериращите се таблици са валидно решение и не крият някакви сериозни ограничения в извличането, триенето и ъпдейтването на данните?

Разбира се ще има отделна таблица за участията, както и една детайли за участието.

CODE
TBL_MATCHES
match_id
date
place
decription
...


TBL_MATCHES_DETAILS
ID
match_id
person_id


Въпроса ми е по-скоро за релациите между хората, как да се реализират. Няколко таблици със загуба на нормализация и повтаряне на колони или една таблица persons, която да има съответните колони за индексиране на самата себе си.

Това мнение е било редактирано от Delegate на 09-03-2019, 20:10
PMEmail Poster
Top
thrawn
Публикувано на: 09-03-2019, 21:13
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2108
Регистриран на: 17.01.17



Това с роднините нещо не го разбрах, но ако гониш рекурсивна релация N:M няма как да минеш без помощна таблица (дори да ползваш рекурсивна релация, което звучи най-логично).

Самите отбори налагат релация 1:M та при тях няма явна нужда от помощни таблици. Но можеш да помислиш за отделна таблица с капитаните на отборите (1:1)

Таблицата с участията се явява помощна (N:M) при рекурсивна релация на таблицата с отборите.
PMEmail Poster
Top
wqw
Публикувано на: 10-03-2019, 10:49
Quote Post


Group Icon
Име: Владимир Висулчев
Група: VIP
Ранг: Почетен член

Мнения: 5994
Регистриран на: 10.06.04



> За всеки мач тиймовете може да са различни, съставени от различни играчи и капитани.

Аз съм играч, обаче в някакъв момент се квалифицирам за капитан. Проблемът е как базата да ме спира да не мога да съм assign-нат за капитан в мачове преди датата ми на преквалификация.

Ако това е някакъв тест, имай предвид че може да има условия, които тепърва ще ти кажат, за да те видят как си рефакторираш дизайна и дали не си го направил прекалено тясно in first place. (Аз поне така бих се "изгаврил".)

cheers,
</wqw>


--------------------
PMEmail PosterUsers Website
Top
thrawn
Публикувано на: 10-03-2019, 11:01
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2108
Регистриран на: 17.01.17



Това с капитана няма как да се случи, защото е редно мачовете да са между отбори (примерния ДДЛ ми се струва погрешен).

За мен, по-сериозния проблем е как да се проектират нещата така, че задължително да има посочен капитан на отбора. Но това може да се реши, ако мачовете не са между отбори а между капитани. Така отбор в който няма посочен капитан няма да може да участва в мачове.
PMEmail Poster
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (2) [1] 2  Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2019 | BG Development | All Rights Reserved
RSS 2.0