Блог Александра Божко
Архивы
Рубрики
Поделись с другими!
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Вдогонку к предыдущему посту. Вопрос об именах таблиц.

Попытаюсь объяснить логику.

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

Собственно, давайте определимся с этими сущностями и связями в нашей задаче. Думаю я на русском, поэтому сначала выделим и обзовем сущности по-русски.

Как процесс выглядит в реальности (без автоматизации)? Я беру лист бумаги и записываю на нем список продуктов, возможно с указанием их количества. С этим листом бумаги я иду в магазин и отмечаю, что куплено, что нет.

Очевидно, что первой сущностью будет сам ПРОДУКТ. Ведь набор наименований продуктов, в принципе, конечен. Да и при автоматизации процесса их удобно выбирать из предустановленного списка.

Я берусь утверждать, что сам листок с записями так же следует выделить в качестве сущности. Я завел машину и тут мне позвонил сосед. Ты, мол в супермаркет? Купи мне пиво и хлеб (с)… И я беру второй лист бумаги и пишу: “Продукты для соседа”. Ставлю дату (вот уже два атрибута у сущности!) и записываю чего он там хочет… Как означить эту сущность? СПИСОК ПРОДУКТОВ – плохая идея. Хотя бы потому, что набор экземпляров сущности ПРОДУКТ тоже а некотором смысле список продуктов. Поэтому более удачным названием будет СПИСОК ПОКУПОК (насколько может быть удачным имя сущности, содержащее слово СПИСОК).

Но нам потребуется и третья сущность. По идее, две первые сущности связаны отношением много-много, и на уровне логической модели ничего добавлять не надо. Но, у нас завис такой атрибут как количество покупаемого продукта. Поэтому вводим сущность, соответствующую записи в списке покупок. И опять логично бы было назвать эту сущность СПИСОК ПРОДУКТОВ и опять это не совсем хорошая идея. Я просто решил обозначить эту сущность комбинацией имен связанных сущностей – СПИСОК ПОКУПОК – ПРОДУКТ. А, поскольку это не совсем удобочитаемо, то просто – СПИСОК-ПРОДУКТ.

Возможно, название ПУНКТ СПИСКА ПРОДУКТОВ (Shoping List Item) тоже имеет право на существование.

ERModel

Теперь на основе полученной модели надо создать таблицы. Естественно, что их имена должны либо транслитерироваться, либо переводиться. Я выбрал последний вариант.

Product, ShopingList, List_Product.

По сути, все “правила” именования сущностей и таблиц носят исключительно рекомендательный характер. И говорить о том, что они названы правильно или не правильно, не совсем корректно. Основной критерий здесь, на мой взгляд, удобство.

Ну, и в контексте данного поста напомню о DB Meta Studio – утилите, которая позволяет вставлять в код элементы структуры БД по заранее заданному шаблону. Читатели моего блога могут получить утилиту в подарок.

Отдельное спасибо Николаю Звереву за присланный отзыв о DB Meta Studio.


Поделись с другими!
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

4 комментария: Создание FireMonkey приложения с использованием FireDAC. #0.5

  • А теперь по быстрому развиваем идею.
    Добавляем сущность, не знаю как даже назвать, пусть будет “КЛАСС_ПРОДУКТА”. Фактически, описывает отдел магазина, в котором можно взять продукт (или магазин, если мы живем в месте, где лампочки продаются в магазине Свет, а хлеб – в булочной). Ну, куда “прилепить” связь, думаю, и так понятно.
    Кол-во в сущности СПИСОК-ПРОДУКТ. Придется разбить на 2 поля – собственно кол-во и ед. измерения, котрая тоже есть справочник. Для демо не обязательно, но если уж делать… Но тогда сразу возникает задача о пересчете ед. измерения…
    Кстати, если все это сибирать под iOS и/или Android, то тут возникает задача автоматического чтения штрих-кода и отметки о выполнении и рассчете суммы к оплате, а это новые поля в сущностях :)

    ЗЫ. В списке поддерживаемых DB в описании DB Meta Studio уберите повторяющуюся DB2. Так же неплохо было бы указывать версии Oracle и MS SQL Server, с которыми тестировалась программа, т.к. там есть некоторые нюансы с типами полей в зависимости от версии.

    • Нет, реальное приложение никто из этого делать не собирается. Модель можно усложнять до бесконечности. Я просто объяснил логику именования таблиц.
      Да, по DB Meta Studio учту, спасибо.

  • Такая симпатичная идея и тут же “… реальное приложение никто делать не собирается.” Непорядок.

    • Реальные приложения подобного плана существуют. Например тот же Купи Батон. А данное приложение носит исключительно академический характер.

Оставить комментарий

Ваш email не будет опубликован. Обязательные поля отмечены *

Вы можете использовать это HTMLтеги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Продукты DevArt
Купить онлайн:



Читай русскоязычные Delphi блоги
Каталог блогов Blogdir.ru
Яндекс.Метрика