На этом уроке мы перечислим поля таблиц Client и Book. Каждое поле этих таблиц потребует подробных комментариев, почему так, как можно сделать иначе, какие могут быть ошибки и так далее.
Дата отправки отчёта:
15 сентября 2017 г.
Задание выполнено: за
47 мин.
Чему научился:
Еще раз узнал много полезного про БД и нормальные формы.
Что было сложным:
Ничего сложного.
Комментарии:
Вообще плохая идея делать в таблице phone1, phone2. С моей точки зрения для этого лучше сделать табличку с 3 полями - id, тип обратной связи, и поле value в котором содержится информация. Типом обратной связи может быть телефон, адрес, скайп, аська, емайл или явка с газеткой в полдень у фонтана (шучу - для разведчиков - чтобы никто не просчитал) - вот это будет очень формализовано. Правда что плохо в таком подходе - надо будет плести соединения таблиц друг с другом. Как показывает практика это не всегда нужно - как правило люди оставляют телефон или e-mail и все. Это я просто если полностью взять и формализовать вид обратной связи. Я даже кстати не знаю как эту таблицу назвать.
Начал вроде бы ругать, а к концу уже и согласился с текущими реалиями. Если что-то не нравится или считаешь, что нужно реализовать по другому, делай и показывай результат, критиковать может каждый. =)
возможно прокатит создание таблицы contacts, в которой указывать тип контактов (телефон, емайл и тд), и связать ее с таблицей пользователей. а вид обратной связи в любом случае будет формализован: id, тип и значение. Неформализуемым будет, если ты хочешь сделать классы, чтобы на каждый вид был какой-то функционал - по емайлу чтобы программа письма слала, по телефону смс/ммс, скайп обзванивала... А если чисто для хранения информации - то в формализованном виде норм
Даже так прокатит. Ты просто создаешь еще одну табличку ContactActions - и в ней указываешь - если e-mail, то слать письма, если телефон то слать смс, если скайп, то можно сообщение в скайпе. Дальше указываем интерфейсы которые будем дергать, а остальное обрабатывает либо сервак, либо клиент.
Научился: Понять зачем нужны разные поля Трудности: Придумать какие поля еще надо были бы обезательны
Всегда при регистрации спрашивают фамилию и дату рождения понял почему вы отказались от EF.
Насчет адреса можно было при его заполнение написать пару полей в форме а все сохранить в одно поля
И еще насчет адресса можно попробывать использовать (google maps api address geolocation x,y) там есть автокомплите подстановка целого аддреса. из минусов если новый район или поселение какоето новое или маленкое то по названию может и ненайти
Научился: В таблицу Client неплохо было еще записать год и дату рождения клиента - year (date of birth), Кроме того, не знаю, насколько нужно поле address, думаю phone и e-mail - вполне достаточно, тем более, что эти поля могут послужить для составного первичного ключа поскольку в любом случае являются уникальными.
