Дизайн на база данни за уебсайт на система за резервация на сватбена фотография

Наистина съм заседнал в най-добрия начин за внедряване на тази база данни.

Ето моят проблем: Базата данни е да съхранява информация за клиентите на сватбена фотография.

  • Потребителят може да се регистрира в моя сайт, да въведе подробностите за своята сватба и да получи своя собствена „страница на сватбения профил“. Те могат да направят това, без да се налага да снимаме сватбата им.

  • По всяко време потребителят може да резервира среща, сватба или годеж. Уебсайтът ще провери дали сме на разположение. (сватбите имат предпочитание пред срещите, така че клиент, който иска да резервира сватба в ден, в който имаме среща, срещата ще бъде маркирана за пренасрочване)

  • Трябва също да можем да резервираме почивни дни. В тези дни не може да се резервира снимане на сватба/среща/годеж.

  • разходи за годежни снимки и предварителна такса. При сватби се плаща депозит до 14 дни или датата се освобождава отново. Срещите са безплатни.

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

Мисля, че това, което ме отблъсква, е фактът, че може да има няколко сватби в един и същи ден (за хора, които просто искат сватбен профил), но само една РЕЗЕРВИРАНА сватба на ден.

Преглед на таблици

Значи съм разбрал напълно това? или съхранявам всички срещи в една таблица и използвам таблица "тип среща".

ТОЛКОВА ТОЛКОВА Закъсал, надявам се, че можете да ми помогнете!

P.S. Пропуснах повечето полета, за да го направя по-лесно за разбиране.


person Lee Mark Smith    schedule 05.08.2014    source източник


Отговори (1)


Бъдете прости като начало. Идентифицирахте много от съществителните, които трябва да съответстват на обекти:

ПОТРЕБИТЕЛИ СВАТБИ ГОДЕЖ_СНИМКИ СРЕЩИ НЕДОСТЪПНИ ДАТИ ПЛАЩАНИЯ

Бих предложил, че СВАТБИТЕ, ГОДЕЖНИТЕ_СНИМКИ, СРЕЩИТЕ и НЕДОСТЪПНИТЕ са всички видове резервации. Бихте могли да имате само:

ПОТРЕБИТЕЛСКИ РЕЗЕРВАЦИИ - това има дата и може би статус BOOKING_TYPE (сватба, среща, годежни_снимки, недостъпно) ПЛАЩАНИЯ

Може да пожелаете да опаковате всички неща, закупени от потребителя, свързани с една сватба, в ТРАНЗАКЦИОННО образувание и т.н., което ще позволи едно плащане да бъде съпоставено с множество резервации. Когато някой от служителите ви не е на разположение, той може да има резервация от тип почивка и т.н.

Може да има 2 вида ПОТРЕБИТЕЛИ - вашият фотографски персонал, който е назначен за резервация, и вашият клиент.

Въз основа на статуса на резервацията, напр. ПОТВЪРДЕНО, ИЗЧАКВАЩО, ЗАВЪРШЕНО и датата, на която вашата бизнес логика може да изпрати искания за плащане, последващи действия и т.н.

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

person kayakpim    schedule 06.08.2014
comment
Здравейте, благодаря за приноса, много го оценявам. Мислех да го направя по този начин. Но когато се опитах да го проектирам, срещнах няколко проблема. Основно за сватба трябва да съхраня различен набор от данни. Например информацията за сватба ще включва местоположения, списъци с гости, препоръки за настаняване, предложения за подаръци, история на двойката и т.н. Така че предполагам, че това трябва да се съхранява в друга таблица и да се свързва по някакъв начин? - person Lee Mark Smith; 06.08.2014
comment
Моделът на данни е там, за да съхранява вашите данни ефективно и да направи приложението лесно за разработване и поддръжка. Би било напълно възможно да се предположи, че клиентът винаги ще има една или повече консултации, едно или повече снимки за годеж и поне една сватба и ще закачи цялата информация за сватбата. Това потенциално би затруднило, ако решите, че искате да се разклоните в други видове бизнес в бъдеще. Ако сватбата има толкова много допълнителни данни, свързани с нея, няма причина тя да не може да има свой собствен обект. - person kayakpim; 07.08.2014
comment
Не го премисляйте като начало и се опитайте да хвърлите нещо заедно. Прочетете за нормалните формуляри и ги използвайте като насоки, а не като закон. Помислете как ще изглеждат екраните за въвеждане и отчетите и вижте дали ще бъдат възможни/лесни за изпълнение със структурата, която имате - person kayakpim; 07.08.2014