Лучшие практики для разработки таблиц базы данных для хранения URL на веб-странице
Прямой вопрос:
Каковы лучшие практики для разработки таблиц базы данных для хранения URL-адресов, настроенных на странице.
Наш вариант использования:
Мы провели обсуждение дизайна и не смогли сделать вывод о том, что является правильным дизайном. Мы пишем страницу с URL-адресами, встроенными в таблицу. Так выглядит страница
....content(some text)...
a |b |c |d
text |url |url |url
text |url |url |url
text |url |url |url
....content(some text)...
Идея состоит в том, чтобы настроить эти URL-адреса в базе данных таким образом, чтобы изменения URL-адреса не требовали развертывания при каждом изменении URL-адреса.
EDIT> a,b,c,d являются заголовками таблицы. Хотя содержание в разделе a будет нормальный текст содержание под b,c,d будут гиперссылки.
Учитывая все это, что должен дизайн таблицы для этой структуры. Мы рассмотрели две схемы:
(a,b(url),c(url),d(url)) #dependent on table design. advantage: written code would
#be very simple and would not be dependent on the number
#of entries in the table.(a simple for loop would
#suffice for presentation logic). Disadvantage: if table
#changes in future, this table is doomed.
#EDIT>a,b,c,d are place holders to represent that content
#represent the headers of table.
(id, url) #advantage: Generic enough to encompass any url.
#disadvantage: This would require presentation layer changes in
#case of new addition of new row.
#EDIT>id is just a number to identify this url and would be used to
#refer while identifying this from presentation layer.
Мы не смогли прийти к выводу, с чем из этого лучше пойти, поскольку у каждого есть свой компромисс (пока мы что-то не упустили). Или все это не хорошо.
Мы используем NoSql Store и Jsp для написания логики внешнего интерфейса (презентации).
РЕДАКТИРОВАТЬ> Следующее может быть тип изменений, которые могут произойти с таблицей:
- добавление нового ряда (часто).
- удаление существующего ряда (часто).
- Порядок столбцов может меняться (но редко).
- Изменение количества столбцов (очень редко, не думаю, что когда-либо случалось, но может случиться).
- Изменение базового URL(изначально поддерживается в обоих проектах, поэтому не важно).
Основной проблемой здесь являются затраты на техническое обслуживание (как в представлении, так и во внутренней части), которые будут вызваны любым из рассмотренных проектов.
EDIT2>
Так что этот проект только о написании внешнего интерфейса для уже существующих сервисов. Нам не приходится иметь дело с так называемым состоянием приложения. Но на определенной веб-странице было несколько URL-адресов (встроенных в таблицу, о которой я упоминал), и бизнес-требованием было не развертывать (этот фрагмент кода) каждый раз, когда кто-то отправляет запрос на изменение (например, изменение существующего URL-адреса, который самый частый тип изменений). Таким образом, вся информация об URL-адресах должна быть перемещена в базу данных и запрашиваться при загрузке страницы (или может быть предварительно загружена, чтобы мы не снижали производительность страницы) с веб-страницы. Теперь эта дискуссия была о разработке соответствующей таблицы для этого использования.
1 ответ
TL;DR:
Уровень представления представляет что- то: (часть) состояние уровня приложения. Состояние приложения дизайна независимо от представления.
Предвидя изменения
Минимизируйте влияние изменений на прикладном уровне на уровень представления (или на других пользователей), предлагая состояние (база данных / API), которое скрывает информацию. Это означает , что нужно расставить приоритеты для вероятных изменений и предложить интерфейс, секретная информация о котором является текущим ( pdf).
Например, следующие apis становятся все более общими, но допускают все больше и больше изменений в списке: "собака", varchar(3), varchar(n), список символов, строка. Соответствующий код может быть следующим: print "dog", для i=1..3 print s[i], для i=1..n print s[i], для s.iterator() print s.next(), s.print().
Чем больше изменений, тем более общий доступ. Поэтому найдите инженерный баланс между вероятностью и размером изменений по сравнению с неясностью и расчетными затратами на универсальность.
Прикладной уровень выходит за рамки представления
Рассмотрим настольную игру. На игровом поле есть игроки, счета, ходы, правила и места, некоторые из которых находятся там, где находятся игроки и т. Д. Но коробки в магазинах могут иметь разную графику, разные физические материалы, разные жетоны, другой текстовый формат, разные языки; некоторый текст или графика будут не переводами, а аналогами; видео версия имеет свою собственную презентацию в свете с командами, заменяющими действия; Сетевая многопользовательская версия имеет несколько презентаций одновременно. Отдельная презентация от состояния игры.
Сначала правильно спроектируйте базу данных / API для состояния приложения ("игра") независимо от какой-либо презентации ("коробка"). Воплотите это в СУБД. Затем презентация запрашивает / обращается к этому состоянию / API. Определите текст URL и идентификаторы в состоянии приложения, в частности, не предполагая ничего о представлении (что будет отображаться, какой будет формат и когда). (Но вы не ответили на мои комментарии по этому поводу.) Предположительно, существует либо таблица abcd в состоянии приложения, либо ее нет, но она может быть выражена как запрос других таблиц, которые есть. Определитесь с этими таблицами и любыми другими, особенно не предполагая представления. (Но вы не ответили на мои комментарии по этому поводу.) Этот дизайн должен скрывать, какой из ожидаемых вариантов на самом деле является текущим прикладным уровнем.
Затем напишите уровень представления для запроса / доступа к этому состоянию приложения.
Реализация уровня представления будет иметь свое собственное состояние. Он может поместить все это в СУБД или любой другой ресурс. (Но вы не ответили на мои комментарии по этому поводу.) Не путайте использование СУБД приложением с использованием его на уровне представления. СУБД просто обслуживает двух мастеров. Даже если его уровень решает, его состояние помещает таблицы приложения и представления в одну и ту же базу данных.
...как можно больше
Состояние приложения / API-интерфейс всегда частично зависит от того, какие запросы / запросы должны быть выполнены, и от архитектуры. Реляционные базы данных минимизируют это для соответствующих приложений. В нереляционной реализации на дизайн больше будут влиять конкретные запросы / доступы уровня представления, а также все пользователи приложения.
Ответ
Насколько это возможно, не помещайте abcd или url-идентификаторы или другое состояние приложения в базу данных по причинам уровня представления. Проектируйте состояние / API уровня приложения независимо от уровня представления. Это должно дать вам возможность ответить на ваш вопрос подробно. (Но вы не ответили на мои комментарии по этому поводу.)