|
|
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
В семнадцатой строке ошибка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2010, 23:02 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
SERG1257, невижу, где? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2010, 03:57 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
авторневижу, где?Там где условия задачи Я сильно сомневаюсь что вы это будете читать, но ссылку все же приведу http://www.citforum.ru/howto/smart-questions-ru.shtml ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2010, 05:32 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
полная картина происходящего ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2010, 06:17 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
SERG1257, Скажите пожалуйста я правильно спроектировал базу данных для сайта. Если нет то прошу указать мне на мои ошибки и привести (по возможности) правильный пример. Спасибо! )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2010, 06:20 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
или с внешними ключами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2010, 06:57 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
авторСкажите пожалуйста я правильно спроектировал базу данных для сайта.Для этого надо достать условия задачи. Попробую вам помочь. Этап номер один: проводим логическое моделирование на словах, поэтому упрощаем донельзя. Итак у нас есть некий сайт. У сайта есть список пользователей aka авторы. Авторы могут принадлежать нулю, только одной, большому числу групп. У каждого автора может быть ноль, один или несколько документов У каждого документа может быть ноль, только одно, конечное число (максимум два, три, n) или бесконечно много описаний, ключевых слов, заголовков (нужное подчеркнуть) Документы могут быть показаны в виде иерархии (документы в иерархии должны принадлежать одному автору или могут разным?) Типичными запросами являются поиск автора по логину список документов одного автора список документов по ключевым словам. (добавьте) какие запросы нужны для поддержания иерархии? Типа дай мне все документы подчиненные этому с уровнем вложения не более двух Это для начала. Особо обращаю ваше внимание на четкое понимание - конечного числа ( ноль, только одна, не больше пяти ) против сколько угодно . Несмотря на соблазн объявить сколько угодно это означает введение дополнительной таблицы. Например ограничив список ключевых слов десятью (пятнадцатью, двадцатью) вы избавляетесь от дополнительной таблицы и ускоряете поиск и модификацию. Важно понимать, что расширение этого магического числа означает патч на базу и приложение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2010, 07:02 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
SERG1257, Авторы могут принадлежать нулю, только одной , большому числу групп У каждого автора может быть ноль, один или несколько документов У каждого документа может быть ноль, только одно , конечное число (максимум два, три, n) или бесконечно много описаний, ключевых слов, заголовков (нужное подчеркнуть) Документы могут быть показаны в виде иерархии (документы в иерархии должны принадлежать одному автору или могут разным?) Типичными запросами являются: - поиск документа по имени - поиск документа по автору - поиск документа по заголовку - поиск документа по дате Также: - поиск автора по логину - список документов одного автора - список документов по ключевым словам какие запросы нужны для поддержания иерархии? Типа дай мне все документы подчиненные этому с уровнем вложения не более двух Типа дай мне все документы по имени ну и более понятная схема ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2010, 08:08 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
Тогда имеем Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. Внешние ключи надо проиндексировать Иерархия реализуется более чем одним способом http://www.sql.ru/articles/mssql/2005/061904TreesInSQLdatabases.shtml выбирайте какой вам понравится. У вашего способа есть свои недостатки. По поводу дат. Я не понял почему вы не пользуетесь стандартным типом Дата. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2010, 08:53 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
Вот ссылка на Целко http://www.sql.ru/articles/mssql/01091502TreesInSQL.shtml ссылка старовата, но общая идея должна быть понятна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2010, 08:59 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
SERG1257, в итоге мы пришли к тому с чего начали, вы вообще на диаграму смотрели? спасибо конечно, но ничего нового я не услышал.. INNODB Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. MYISAM Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2010, 11:08 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
А зачем вы вынесли заголовок, описание и тело документа по отдельным таблицам? Я не видел в условиях задачи необходимость вертикального секционирования, или это особенность MySQL KISS schizophrenic в итоге мы пришли к тому с чего начали, вы вообще на диаграму смотрели? спасибо конечно, но ничего нового я не услышал.Зато вы получили ответ на первый пост, плюс огласили условие задачи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2010, 18:05 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
Вот мне тоже не кажется логичной подобная декомпозиция. schizophrenicСкажите пожалуйста я правильно спроектировал базу данных для сайта. Если нет то прошу указать мне на мои ошибки и привести (по возможности) правильный пример Нет, не правильно. Ошибка в излишней декомпозиции. Схема избыточна - увеличивается объем хранимой информации, сложность и, как следствие, время выполнения запросов. Правильные примеров в ответах на ваши посты уже как минимум два. schizophrenicв итоге мы пришли к тому с чего начали, вы вообще на диаграму смотрели? спасибо конечно, но ничего нового я не услышал.. Совершенно не к тому же. Даже не близко. Serg1257 привел свою схему данных по поставленной задаче. Она несколько расширяет функционал поставленной задачи, но так же и очень сильно отличается от того, что привели вы. SERG1257Я не видел в условиях задачи необходимость вертикального секционирования, или это особенность MySQL Нет такой особенности MySQL. Шиз, видимо, неправильно понял третью нормированную форму. В частности, выражение " Ничего, кроме ключа ". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2010, 08:19 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
Вот как таз под 3НФ я и переработал структуру! Lemegeton..Схема избыточна - увеличивается объем хранимой информации, сложность и, как следствие, время выполнения запросов..Особое внимание обратите на таблицу Dates, она спроектированы таким образом что таблицу используют как таблицы Documents так и Authors в следствии чего мы получаем единую гриппу дат для четырех внешних индексов. А также к таблице Names идет обращение по четырем внешних индексам из таблицы Documents... А ведь это логично на мой взгляд, зачем многократно использовать одни и те же данные, правильно? остальные таблицы уникальные, и хоронят в себе различные данные (не повторяющейся). Делайте выводы! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2010, 10:53 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
вот пример выборки: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2010, 10:57 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
schizophrenic и хоронят в себе различные данные Очень правильное определение. Именно хоронят . Вашу схему можно использовать как пример того, как механические попытки нормализовать все что можно приводят к совершенно абсурдным результатам. Не надо создавать таблицы-справочники на каждое поле. Да, возможно таким образом вы сократите размер базы (хотя не факт, ключи тоже надо хранить). Но сейчас диски дешевы, и нет ничего страшного в том, что база будет занимать в 100 Мб вместо 50. А вот проблем с производительностью запросов вы получите кучу. Ведь каждый раз, когда вы джойните таблицы в запросе, серверу приходится лезть в одну таблицу, лезть в другую, и тем или иным алгоритмом соединять их. Это медленне чем просто прочитать одну таблицу. Я уже и не говорю о ситуации когда вам надо будет делать выборку с условием по двум полям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2010, 11:34 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
Senjaхотя не факт, ключи тоже надо хранитьа что по вашему делают таблицы Documents и Authors- хранят ключи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2010, 11:46 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
schizophrenicВот как таз под 3НФ я и переработал структуру! К нормализации можно привести несколькими способами. Ваш далеко не лучший с точки зрения реализации. schizophrenicОсобое внимание обратите на таблицу Dates, она спроектированы таким образом что таблицу используют как таблицы Documents так и Authors в следствии чего мы получаем единую гриппу дат для четырех внешних индексов. Вы забыли, что поля, хранящие ключ даты в других таблицах (Id_Created, Id_Changed и им подобные) имеют размерность INT, которая РАВНА размеру в байтах типа TIMESTAMP. То есть, что хранить ключ, что хранить собственно дату -- разницы в байтах никакой. Вы ничегошеньки не выиграли, а только проиграли целую излишнюю таблицу, индексы в ней и работу с ней. Но давайте обратим особое внимание на таблицу Dates. Допустим, есть два документа: Документы Текст Id_ChangedПервый пост 1Второй пост 1 Авторы Id_authorizedВася 1Петя 1 Даты Id date1 2010-01-01 12:00:00 Вопрос. Что, в рамках вашей базы, надо сделать, чтобы у первого документа и только у первого и только документа изменилась дата обновления? schizophrenicкто скажет что это долгая пробежка по таблицам? EXPLAIN и PROFILING, когда у вас будет миллион записей в таблице документов и три миллиона записей в таблице дат. На не хай-эндовом железе тормоза начнутся при объеме на несколько порядков меньше. Ну, может еще все те, кто фалломорфировал или фалломорфируют в будущем от подобного подхода. Сделайте "рыбу" и убедитесь сами, если не верите никому на слово. schizophrenicа самое главное то что данная структура шикарно оптимизирована по кеширование запросов и таблиц (MySQL) В силу особенностей мозгов разработчиков кеширования MySQL, к кешированию имеют отношения только запросы и их значения. От структуры это не зависит. schizophrenicДелайте выводы! Делаем выводы. 1. База избыточна. Причем сильно избыточна. 2. Работа с такой структурой -- каторжный труд. Особенно изменение и удаление аттрибутов записей документов. 3. Аналогичные предоставленные решения более простые, быстрые и меньшие по объему. В качестве отступления. schizophrenic , а зачем ви спрашиваете, если считаете свое решение единственно верным? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2010, 13:07 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
LemegetonВопрос. Что, в рамках вашей базы, надо сделать, чтобы у первого документа и только у первого и только документа изменилась дата обновления?Ответ. Поменять ID на другую дату если она есть, или создать новую в обратном случае. Таким образом сотни документов созданных в определенный день или модифицированных, будут иметь один ID где в таблице с датами будет всего одно значение.. Lemegetonкогда у вас будет миллион записей в таблице документов и три миллиона записей в таблице датесли у меня будет такое количество записей, то я не буду парится на это счет, а буду отдыхать на Кенарах )) LemegetonВ силу особенностей мозгов разработчиков кеширования MySQL, к кешированию имеют отношения только запросы и их значения. От структуры это не зависит .это надо запомнить )) LemegetonВ качестве отступления. schizophrenic, а зачем ви спрашиваете, если считаете свое решение единственно верным?Я до последнего спорю всегда, потом собираю все за и против и делаю выводы, на счет рыбы, сейчас займусь этим вопросом и обязательно отпишусь Спасибо! да кстати без рыбы такой запрос Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. Status Durationstarting 0.000281Opening tables 0.000870System lock 0.000009Table lock 0.000015init 0.000100optimizing 0.000040statistics 0.000325preparing 0.000033executing 0.000005Sending data 0.000038end 0.000006query end 0.000005freeing items 0.003784logging slow query 0.000006cleaning up 0.000018 обратите внимание на Opening tables и freeing items так что на счет количества таблиц я бы поспорил! это сам запрос! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2010, 13:39 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
EXPLAIN запроса idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra 1.0SIMPLEPageconstPRIMARY.ValueValue34const 1.0Using index 1.0SIMPLEAttributesconstPRIMARY.ValueValue1const 1.0Using index 1.0SIMPLEDocumentsconstFK_Documents_Name_ID.FK_Documents_Attributes_IDFK_Documents_Name_ID4const 1.0 1.0SIMPLEDescriptionsconstPRIMARYPRIMARY4const 1.0 1.0SIMPLEKeywordsconstPRIMARYPRIMARY4const 1.0 1.0SIMPLETitlesconstPRIMARYPRIMARY4const 1.0 1.0SIMPLEBodysconstPRIMARYPRIMARY4const 1.0 1.0SIMPLETemlatesconstPRIMARYPRIMARY4const 1.0 1.0SIMPLECreatedconstPRIMARYPRIMARY4const 1.0 1.0SIMPLEChangedconstPRIMARYPRIMARY4const 1.0 1.0SIMPLEAuthorconstPRIMARYPRIMARY4const 1.0 1.0SIMPLENameconstPRIMARYPRIMARY4const 1.0 1.0SIMPLESurnameconstPRIMARYPRIMARY4const 1.0 1.0SIMPLENicknameconstPRIMARYPRIMARY4const 1.0 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2010, 14:08 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
таблицу c датами вынести - это что-то новенькое ИМХО, вы слишком декомпозировали (как вам уже говорили выше) заголовок, дату и описание - можно оставить в основной таблице обьем данных не уменьшится, так как для каждой статьи будет уникальный заголовок, и описание, просто вы по разным таблица разносите, и заставите потом процессор, прыгать по индексам и джойнить чем меньше join в запросах - тем быстрее он будет выполняться, даже если таблица будет больше в размерах вот интересно, запрос select... ... join titles as tit... join dates as dt... ... where year(dt.value) = 2010 and month(dt.value) = 7 and tit.value like '%audi%' как думаете? оптимизатор, бережливо сперва в таблице с датами пороется, выберет какие id будут в нужном диапазоне, потом по таблице titles, там нужный диапазон id выберет и красиво выберет нужное из таблицы documents, и только потом приджойнит все внешние таблицы? мне почему-то кажется, что он сперва в памяти выстроит общую таблицу, то есть всей таблице documents сделает join внешних таблиц, а потом по ней пробежится с LIKE и просчитает month & year для даты. конечно могу ошибаться, но результат явно не айс будет чтобы проверить на сколько ваш вариант оптималный - сгенерируйте тестовых данных, так чтоб там тыс 5..10 статей было, и погоняйте запросы, желательно в 2..3 потока ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2010, 16:58 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
schizophrenicLemegetonВопрос. Что, в рамках вашей базы, надо сделать, чтобы у первого документа и только у первого и только документа изменилась дата обновления?Ответ. Поменять ID на другую дату если она есть, или создать новую в обратном случае. Таким образом сотни документов созданных в определенный день или модифицированных, будут иметь один ID где в таблице с датами будет всего одно значение..то есть вместо простого апдейта по ид документа надо будет искать нужную дату, если не нашли, то создавать её, потом апдейтить ссылку на неё, а в это время кто-то ещё мог такую же дату ввести... вы серьёзно полагаете, что это проще и удобнее? ЗЫ. в качестве доведённого до абсурда примера предлагаю вам такую структуру: Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2010, 17:05 |
|
||
|
База для сайта #2
|
|||
|---|---|---|---|
|
#18+
tanglirто есть вместо простого апдейта по ид документа надо будет искать нужную дату, если не нашли, то создавать её, потом апдейтить ссылку на неё, а в это время кто-то ещё мог такую же дату ввести... вы серьёзно полагаете, что это проще и удобнее?+1. А как удобно будет искать данные по диапазону дат... закачаешься! )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2010, 17:57 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36736424&tid=1542622]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
177ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
90ms |
get tp. blocked users: |
1ms |
| others: | 209ms |
| total: | 531ms |

| 0 / 0 |
