Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
Страсти-мордасти. Пока не совсем разобрался как пользоваться сервисом. Старый пост почему-то затерся новым… хотя у меня в постах присутствуют оба…
>В окне выше вы можете видеть, как поле customer таблицы заказов слева связывается с первичным ключом (customer_id) таблицы клиентов справа.
Но ни слова не сказано про каскадное удаление и какие есть альтернативы.
Но ни слова не сказано про каскадное удаление и какие есть альтернативы.
Возможно, вы захотите хранить метод платежа или дату платежа. Но это все еще минимальные блоки информации, которые могли бы относиться к заказу. Можно изменить формулировки. Метод платежа — метод платежа заказа. Дата платежа – дата платежа заказа. Таким образом, я не вижу необходимости выносить платежи в отдельную таблицу
А потом, когда БД уже основательно заполнится, внезапно выясняется, что, например, оплата заказа может производиться частями, после чего, начинаются индийские народные танцы вокруг изначально кривой схемы.
Я же говорю, вредная статья.
Эмм… может я чего-то не понимаю, но почему сразу танцы? Делаем отдельную таблицу «payments», заполняем её данными из orders, деплоим новую версию кода, которая использует «payments», домигрируем то, что успело насоздаваться в orders за время деплоя, сносим старые поля в orders. Всё без особого геморроя, и даже с zero downtime, скорее всего.
Все зависит от объемов данных. В любом случае, легче сразу правильно спроектировать, а не вводить совершенно искусственное ограничение 1 заказ = 1 платеж
«Знал бы заранее где упаду, соломки подстелил бы.»
Невозможно сразу учесть всё. И, опять же, из попыток учесть ВСЁ иногда рождаются монстры, ярко иллюстрирующие пословицу «из пушки по воробьям». Мне в этом плане очень нравится философия 37signals — «Do less». «Делай только то, что необходимо». Конечно, надо всегда помнить что потенциально какую-то часть приложения надо будет расширить или отрефакторить. Но когда клиент просит сделать ему рогатку — не стоит строить экзоскелет с встроенным гранатометом и с заделом под терминатора на будущее.
Невозможно сразу учесть всё. И, опять же, из попыток учесть ВСЁ иногда рождаются монстры, ярко иллюстрирующие пословицу «из пушки по воробьям». Мне в этом плане очень нравится философия 37signals — «Do less». «Делай только то, что необходимо». Конечно, надо всегда помнить что потенциально какую-то часть приложения надо будет расширить или отрефакторить. Но когда клиент просит сделать ему рогатку — не стоит строить экзоскелет с встроенным гранатометом и с заделом под терминатора на будущее.
Речь не о том чтобы предусмотреть все, а как раз о том, чтобы не делать лишних предположений, таких как «я не вижу необходимости выносить платежи в отдельную таблицу». Лично я не вижу необходимости НЕ выносить платежи в отдельную таблицу, если понятно о чем я.
На мой взгляд, цикл этих статей характеризуется тем, что автор сознательно старается «понизить планку» порога вхождения, стараясь объяснить максимально просто, порой, достаточно сложные вещи. Мне не нравится такой популизм. Честно говоря, я с ужасом ожидаю объяснения транзакций.
Если оно вообще будет, конечно
На мой взгляд, цикл этих статей характеризуется тем, что автор сознательно старается «понизить планку» порога вхождения, стараясь объяснить максимально просто, порой, достаточно сложные вещи. Мне не нравится такой популизм. Честно говоря, я с ужасом ожидаю объяснения транзакций.
Если оно вообще будет, конечно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Руководство по проектированию реляционных баз данных (4-6 часть из 15) [перевод]