Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Архитектура БД
Форумы портала PHP.SU » PHP » SQL и Архитектура БД » Архитектура БД

Страниц (5): [1] 2 3 4 5 »
 

1. Hapson - 27 Июня, 2013 - 00:35:24 - перейти к сообщению
Вроде как созрел уже что-то писать. Решил сначала написать блог, для себя любимого)))
И тренировка и пригодится.
Естественно начал с БД. Сижу уже вот 3 вечера - думаю.
Вообщем будут статьи от меня, и пока только от меня. Пока...
Комментарии как от зарегистрированных пользователей, так и от незарегистрированных.
Ну и категории конечно.
Вот че я надумал
CODE (SQL):
скопировать код в буфер обмена
  1. /* Category */
  2. | id_cat | id_user |  alias   | title   | created | MODIFY |status |
  3. | int(5) | int(5)  | char(100)|char(100)|datetime |datetime|tinyint|
  4. --status: 1 - публикуется, 2 - на модерации, 3 - не публикуется, 0 - удалена
  5.  
  6. /* Category_info */
  7. | id_cat | description |
  8. | int(5) |  char(255)  |
  9.  
  10. /* Articles (Статьи) */
  11. | id_article | id_user  | copyrights | alias   |  title  | keywords | description | robot | article | cnt_comments | created | MODIFY  | end_public | STATUS  |
  12. |   int(5)   |  int(5)  |   tinyint  |char(100)|char(100)|char(255) | char(255)   |tinyint| text    |   int(5)     | datetime| datetime| datetime   | tinyint |
  13. --status: 1 - публикуется, 2 - на модерации, 3 - не публикуется, 0 - удалена
  14.  
  15. /* Articles_raiting (рейтинг статей) */
  16. | id_article | rating_all | rating_good | rating_bad |
  17. |   int(5)   |   int(5)   |   int(5)    |   int(5)   |
  18.  
  19. /* Comments (комментарии) */
  20. | id_comment | id_article | comment | STATUS |
  21. |   int(5)   |   int(5)   | text    |tinyint |
  22. --status: 1 - публикуется, 2 - на модерации, 3 - не публикуется, 0-удален
  23.  
  24. /* Comments_rating (рейтинг комментариев) */
  25. | id_comment | rating_all | rating_good | rating_bad |
  26. |    int(5)  |  int(5)    |  int(5)     |   int(5)   |
  27.  
  28. /* Comments_of_reg (комментарии зарегистрированных пользователей) */
  29. | id_comment | id_user |
  30. |   int(5)   |  int(5) |
  31.  
  32. /* Comment_of_not_reg (комментарии незарегистрированных пользователей) */
  33. | user_name | user_email |
  34. | char(60)  |  char(50)  |
  35.  
  36. /* Users (пользователи) */
  37. | id_user | login  | password | role  | STATUS | email  | date_register |
  38. | int(5)  |char(50)|  char(50)|tinyint| tinyint|char(50)|   datetime    |
  39. --status: 1 - активирован, 2 - ожидает активации, 3 - бан, 0 - удален
  40.  
  41. /* User_info (доп. инфа о пользователях) */
  42. | id_user | site_url  | site_title | name   | Age   | sex   |  city   |
  43. | int(5)  | char(100) |  char(50)  |char(50)|tinyint|tinyint|char(100)|
  44.  
  45. /* Setting (настройки сайта) */
  46. |   url  | keywords | description |
  47. |char(50)|char(255) |  char(255)  |


Вот затык у меня с последней табличкой. Нужна ли она вообще? Это типа какие-то настройки сайта.
Еще что-то туплю с таблицей для галереи: что там храниь? Ну название, title, alias...

Ну и как вообще оно? Я на верном пути?
Может нужно что-то еще?
(Добавление)
ЗЫ
Переводы строк коверкают все...
Лучше скопировать в notepad++.
2. vanicon - 27 Июня, 2013 - 01:39:19 - перейти к сообщению
Hapson
А вам не кажется что многовато таблиц?
Можно было бы объединить Category и Category_info, Articles_raiting и Comments_rating, Comments_of_reg и Comment_of_not_reg, Users и User_info.
Зачем вы их разделяете?
3. Hapson - 27 Июня, 2013 - 08:09:02 - перейти к сообщению
vanicon
В таблице Category_info пока олин столбец - дискрипшен. Он может быть, а может и не быть (скорее всего).
Рейтинг у комментов и статей может быть, а может и нет.
Комменты могут быть от зарегистрированных пользователей, а могут быть от гостей.

Если все объединить, то в таблицах будет много пустых полей. А так во всех таблицах практически все поля будут заполнены. Запросы будут посложнее, но их ведь только раз написать.

Вообщем я как бы следую рекомендациям из книг. В частности МартинГрабер-SQL. Вроде как считается не очень хорошо, если в таблице много пустоты. Размер БД от этого однозначно увеличится.
(Добавление)
Ps
Не знаю, может и правда переборщил...
4. Hapson - 28 Июня, 2013 - 11:12:36 - перейти к сообщению
Ну так как лучше?
Делать несколько таблиц так, чтобы в них были заполнены все поля. Или обобщить немного и пусть будет NULL в некоторых полях?
Прочитал, что вроде объединение замедляет отклик БД.
5. Contr - 28 Июня, 2013 - 12:19:12 - перейти к сообщению
Я тебе дам советы, которые тебе помогут, они мне сразу в глаза бросаются:
1) Ты правильно начал - надо начинать с БД, только много позже - с обертки в виде php
2) Лучший способ продумать архитектуру БД - методом проб и ошибок. Когда сделаешь как тут написал, попробуй составить запросы, которые тебе будут нужный потом (выбрать людей, кто не оставил комментарии... и т.д.). Возможно тебе придется переделать таблицы в БД.
3) Перестань называть таблицы через "_" Придумай короткие названия из одного слова. Тебе потом запросы писать - ты просто оху**шь! Чем короче название таблиц и полей - тем лучше. Со временем поймешь.
4)
Цитата:
Прочитал, что вроде объединение замедляет отклик БД.
забей. Продумай, где у тебя должны обязательно заполняться поля (пиши NOT NULL), где - нет
5) И последнее, но не последнее по важности - не используй CHAR(n). Он добавляет ( и php потом выводит) дополнительные пробелы. Используй ТEXT, а если надо принудительно ограничить длину символов - VARCHAR(n)
6. vanicon - 28 Июня, 2013 - 15:09:38 - перейти к сообщению
Hapson
Архитектура бд это не простая задача как кажется на первый взгляд, здесь я считаю нужным объединить таблицы которые я выше указал, например как вы будите выводить последние комментарии к записи, если у вас будет 2 таблицы комментариев (1 для зареганых, а другая для гостей) ?
Такое разделение только усложнит приложение...
(Добавление)
В некоторых случаях используют и денормализацию данных, для ускорения приложения, поэтому подход к архитектуре бд, напрямую связан со спецификой приложения...
7. LIME - 28 Июня, 2013 - 17:13:08 - перейти к сообщению
Hapson хочу предостеречь от ретивых "советчиков"
Contr давненько такой ереси тут не видел
(Добавление)
http://ruseller[dot]com/lessons.php?[dot][dot][dot]ub=28&id=692
8. AlexAnder - 28 Июня, 2013 - 17:46:25 - перейти к сообщению

Источник урока: net.tutsplus.com/tutorials/other /top-20-mysql-best-practices/
Перевел: Сергей Фастунов
9. Hapson - 28 Июня, 2013 - 18:33:02 - перейти к сообщению
Contr
Имена конечно будут поменьше. Это сейчас, чтобы понимать.
А по поводу char - насколько я помню, то пробелы добиваются в БД, но при выборке они отбрасываются.

vanicon
Да, наверно надо кое-что объединить. Но например Дискрипшен категорий можно же вывести в отдельную таблицу. Так как скорее всего его не будет.

LIME
Спасибо за ссылку. Читаю

ЗЫ
Вот еще не пойму, какую таблицу делать для картинок? Хранить там id и линки на картинки?
10. vanicon - 28 Июня, 2013 - 18:37:32 - перейти к сообщению
Hapson пишет:
Но например Дискрипшен категорий можно же вывести в отдельную таблицу. Так как скорее всего его не будет.

Не стоит этого делать, смысла 0, а если надо будет выбрать вместе c категориями и их описание, то что? придется делать "тяжелый" запрос к бд для этого
(Добавление)
Hapson пишет:
Вот еще не пойму, какую таблицу делать для картинок? Хранить там id и линки на картинки?

Да, + еще id поста куда прикреплено фото
11. armancho7777777 - 28 Июня, 2013 - 18:54:14 - перейти к сообщению
vanicon пишет:
Не стоит этого делать, смысла 0

Почему же?
Предположим:
все таблицы в InnoDB, и надо реализовать полнотекстовый поиск,
который движок InnoDB не поддерживает, то описания и габаритные тексты выводятся в отдельную таблицу с движком MyISAM.
(Добавление)
vanicon пишет:
а если надо будет выбрать вместе c категориями и их описание, то что?

Объединение таблиц в запросах (INNER JOIN / LEFT JOIN)
12. vanicon - 28 Июня, 2013 - 18:57:16 - перейти к сообщению
armancho7777777 пишет:
который движок InnoDB не поддерживает, то описания и габаритные тексты выводятся в отдельную таблицу с движком MyISAM.

А если для этого использовать специальные утилиты такие как сфинкс?
armancho7777777 пишет:
Объединение таблиц в запросах (INNER JOIN / LEFT JOIN)

vanicon пишет:
придется делать "тяжелый" запрос к бд для этого
13. armancho7777777 - 28 Июня, 2013 - 18:58:43 - перейти к сообщению
vanicon пишет:
придется делать "тяжелый" запрос к бд для этого

А хранимые процедуры зачем?
(Добавление)
vanicon пишет:
А если для этого использовать специальные утилиты такие как сфинкс?

Что, заняться нечем?)
14. vanicon - 28 Июня, 2013 - 19:00:02 - перейти к сообщению
armancho7777777 пишет:
А хранимые процедуры зачем?

Конечно можно сделать, но это же костыль, и при чем при масштабировании он и поперек может встать, зачем так заморачиваться ради 1 поля?
(Добавление)
armancho7777777 пишет:
Что, заняться нечем?)

Думаю это лучше чем
armancho7777777 пишет:
то описания и габаритные тексты выводятся в отдельную таблицу с движком MyISAM.

хотя не уверен...
15. armancho7777777 - 28 Июня, 2013 - 19:01:35 - перейти к сообщению
vanicon пишет:
придется делать "тяжелый" запрос к бд для этого

InnoDB по барабану.
С грамотной расстановкой индексов полей он Вам выплюнет на раз-два.

 

Powered by ExBB FM 1.0 RC1