|
|
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Мне нужно спроектировать базу данных так, чтобы одном запросе я могу сразу все данные получить. Запрос такой, что я ввожу текст, получить должен список пословиц, их аналогов и их описание. У меня есть список русских пословиц и список других (английских, и т.д.). Русская пословица имееет несколько аналогов (может иметь несоклько английских, а также русских аналогов и т.д.). Также есть общее описание (когда употребляется), оно относится к какому-то множеству пословиц (т.е. 4 пословицы, эквиваленты , аналоги , будут иметь 1 описание) Т.е. пользователь ищет пословицу русскую: "блаблаблабла", а я в базе данных должны поискать все аналоги и выдать результат: Искомый вариант: "блаблаблабла". Английские аналоги: "blablablablabla" "WTF" "It's a piece of shit" Когда употребляется: "Когда лень придумать пример, то мы пишем полнейший бред" Я создал 3 таблицы. 1-ая: uid(int), proverbText(varchar); PK = uid 2-ая: uid(int), description(TEXT); PK = uid 3-ая: id(int), rusAnalogvarchar(255), OtherAnalog(varchar(255)), description(int) 3-ая таблциа - это связка между 3 таблицами. Т.е. сначала я ищу текст в 1-ой таблице(1), затем по найденным id я ищу в таблице аналогов описание, нахожу описание по id в 2 таблице(*), затем мне нужно найти аналоги списка таблиц из 1-го подзапроса. Я почти седал заспрос, до *, но уменя уже запрос в 6 строчек, но работает но слишком длинный. Можно спроектировать так, чтобы запросы были поменьше? Преподаватель сказал: "it's a bullshit", также добавил, что это не будет проверять. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 12:59 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
On 11/17/2011 01:59 PM, Jorik12 wrote: > 1-ая: > > uid(int), proverbText(varchar); PK = uid > > 2-ая: > > uid(int), description(TEXT); PK = uid Почему бы description не запихать в первую таблицу ? Это (что ты сделал) декомпозиция, не приводящая ни к устранению аномалий данных, ни к уменьшению хранимого размера данных. description должно быть в первой таблице. Также тут должен наверное быть язык пословици. > 3-ая: > > id(int), rusAnalogvarchar(255), OtherAnalog(varchar(255)), description(int) Нарушение 1НФ, rusAnalogvarchar(255), OtherAnalog(varchar(255)) -- массив полей. description на фиг не нужен. Таблица должна быть типа uid(int), analog_uid(int) причём либо отношение аналога должно быть несимметричным, либо ты должен писать запросы с UNION-ами с двух сторон, либо ты должен всегда вставлять записи AA - BB BB - AA > 3-ая таблциа - это связка между 3 таблицами. Не, это не связка, это дейтвительно bullshit. Тебе надо почитать сначала что-то по проектированию реляционных БД, иначе ты далеко не уйдёш. > Я почти седал заспрос, до *, но уменя уже запрос в 6 строчек, но работает но Запрос на неправильную структуру рассматривать бессмысленно. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 13:11 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
Jorik12, Код: 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. Код: 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. Т.к. нужно хранить аналоги - в prvrb_parent_id пишеш айди пословицы, к которой данный аналог приаттачен. Выбираеш потом - в 1 запросе либо с подзапросом, либо рекурсивным запросом пословицу + ее аналоги. Про рекусривные запросы - читай в доке по своей субд. Преподу - скажи чтоб шел в жопу, иперед тем как "валить" - сказал бы как правильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 13:54 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
On 11/17/2011 02:54 PM, DeathHand wrote: > create table PROVERBS > ( > prvrb_idNUMBER not null, > text CLOB, > prvrb_parent_idNUMBER, > lang_lang_idNUMBER > ) > Т.к. нужно хранить аналоги - в prvrb_parent_id пишеш айди пословицы, к которой > данный аналог приаттачен. Выбираеш потом - в 1 запросе либо с подзапросом, либо > рекурсивным запросом пословицу + ее аналоги. Про рекусривные запросы - читай в Не понятно, с чего ты решил сделать из пословиц дерево. Во-первых, граф аналогов пословиц не факт, что ациклический, во-вторых, он ненаправленный (скорее всего). И главное -- это "многие ко многим" в чистом виде, очевидно, что у одной пословицы может быть много аналогов, и наоборот (потому что отношение симметричное). Так что всё правильно, но для отношения "аналогия пословиц" нужна отдельная таблица связи, "многие ко многим", и ещё к тому же симметричная связь должна быть. > доке по своей субд. Преподу - скажи чтоб шел в жопу, иперед тем как "валить" - > сказал бы как правильно. Не, я согласен с преподом. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 14:03 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
DeathHand, Ну и с коментами к пословицам - разберешься. Тогда нужно добавить еще столбец в PROVERBS, который многими значениями будет указывать на одно значение в таблице COMENTS к примеру. Типа: Код: 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. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 14:12 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
MasterZivТак что всё правильно, но для отношения "аналогия пословиц" нужна отдельная таблица связи, "многие ко многим", и ещё к тому же симметричная связь должна быть. Хм. Каждая пословица имеет уникальный номер. Даже дочерняя(аналог). Аналог, может иметь тоже аналог, что благодаря наличию уникального ключа - так же, становится реализуемо. Вопрос уровня вложенности, данным примером - по сути можно сделать любой уровень. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 14:14 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
MasterZivНе, я согласен с преподом. Я тоже, только сначала покажи примеры - как делать "жесть", научи, разжуй, а потом сношай моск. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 14:15 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
On 11/17/2011 03:15 PM, DeathHand wrote: > Я тоже, только сначала покажи примеры - как делать "жесть", научи, разжуй, а > потом сношай моск. Тут ему не книжка. Книжек полно, пусть читает. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 15:01 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
On 11/17/2011 03:14 PM, DeathHand wrote: > Хм. Каждая пословица имеет уникальный номер. Даже дочерняя(аналог). Что значит дочерняя ? Родительская является аналогом дочереней в той же степени, что и дочерняя -- аналогом родительской. Аналог, > может иметь тоже аналог, что благодаря наличию уникального ключа - так же, > становится реализуемо. Какая на х. разница, уникальный ключ или нет ? Ключ всегда уникальный, ну и что ? Почему дерево ? Дерево -- ациклический направленный граф. Тут отношение аналогии, оно симметрично A =a= B следовательно B =a= A т.е. граф аналогов ненаправленный, и к тому же там могут быть циклы. Скорее всего надо вообще хранить в таблице результат выполнения транзитивного замыкания даже. Может быть даже две таблицы надо -- для хранения изначальных данных, и для храннения замыкания. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 15:07 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
MasterZivOn 11/17/2011 03:14 PM, DeathHand wrote: > Хм. Каждая пословица имеет уникальный номер. Даже дочерняя(аналог). Что значит дочерняя ? Родительская является аналогом дочереней в той же степени, что и дочерняя -- аналогом родительской. Аналог, > может иметь тоже аналог, что благодаря наличию уникального ключа - так же, > становится реализуемо. Какая на х. разница, уникальный ключ или нет ? Ключ всегда уникальный, ну и что ? Почему дерево ? Дерево -- ациклический направленный граф. Тут отношение аналогии, оно симметрично A =a= B следовательно B =a= A т.е. граф аналогов ненаправленный, и к тому же там могут быть циклы. Скорее всего надо вообще хранить в таблице результат выполнения транзитивного замыкания даже. Может быть даже две таблицы надо -- для хранения изначальных данных, и для храннения замыкания. А что курите то, уважаемый? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 15:12 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
MasterZiv Родительская является аналогом дочереней в той же степени, что и дочерняя -- аналогом родительской. Ну и хрен бы с ней, собственно. Имею в парке 100500 баз, аналогичных сабжу, аналогичных тем что я предложил выше. Не комплексуем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 15:14 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
Спасибо за комментарии. Поясню, что и почему как я сделал. Сначала у меня были вот такие записи: авторлибо ты должен всегда вставлять записи AA - BB BB - AA Но я посчитал, что это избыточность, т.к. если 1-ая пословица связана со второй, то и 2-ая ОБЯЗАТЕЛЬНО связана с первой. Не бывает ассиметричности, всегда будет симметричный граф, причем будет повторяющие ключи,, поэтому мне пришлось еще один левый primary ключ создавать, например: id 1 A - B 2 B - A 3 A - C 4 C - A Почему я решил описание во вторую таблицу-связку. Потому что опять же избыточность данных. Например, у 4-х половиц (они являются аналогами) есть 1 описание общее, поэтому я буду хранить кучу избыточных данных. А в моей таблице была симметричная связь. Т.е. блы а сзвяь ТОЛЬКО A - B, а подразумевалось, это то, что и B - A, но это отражалось только в запросах (OR). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 15:30 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
Jorik12, 1) БД должна хранить данные так, как от нее требуется; 2) В БД нет графов - есть записи, ключи, таблицы, индексы и многое другое; 3) Избыточности не бывает - бывает больше записей, чем реально нужно, что бы хранить данные; 4) БД должна быть спроектирована так, чтобы запросы из нее были короче, а массивы данных обратаваемые такиими запросами - меньше; 5) БД должна быть умной. Т.е. имет ограничения и не давать. 6) Связь А-Б и Б-А не существует. Бывает 1-много, 1-1, много-к-много. Есть направление связи - от меньшего к большему; 7) Нормальных форм нет - есть спицифика приложений и особенности работы СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 15:43 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
Jorik12, Вывод - учитесь оперировать земными терминами. Глядишь - объем каши в голове то - поубавиться, да существенно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 15:44 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
> симметричный граф, причем будет повторяющие ключи,, поэтому мне пришлось еще > один левый primary ключ создавать, например: > > id > 1 A - B > 2 B - A > 3 A - C > 4 C - A Лучше именно так данные и хранить. Удобнее будет писать запросы. > Почему я решил описание во вторую таблицу-связку. > Потому что опять же избыточность данных. Нет избыточности. Например, у 4-х половиц (они являются > аналогами) есть 1 описание общее, поэтому я буду хранить кучу избыточных данных. Тогда, извини, тебе надо иметь как отдельную сущность описание, (она у тебя была), и тогда надо было иметь связь между поговоркой и её описанием. У тебя она была, но была в таком виде, что я ничего не понял. В одной таблице нельзя хранить несколько связей. Надо столько таблиц, сколько связей обычно. Так что делай отдельную таблицу связи поговорки с её описанием. Описание одно, поговорок много, 1:M, тогда можно просто в поговорке сделать ссылку на описание (не нужно отдельной таблицы). Хотя если у одной поговорки может быть много описаний -- нужно таблицу связи. > А в моей таблице была симметричная связь. Т.е. блы а сзвяь ТОЛЬКО A - B, а > подразумевалось, это то, что и B - A, но это отражалось только в запросах (OR). Лучше хранить 2 записи, чем писать в 2 раза более сложный запрос. Это по опыту. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 15:52 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
Спасибо, понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2011, 15:57 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
Jorik12Спасибо за комментарии. Поясню, что и почему как я сделал. Сначала у меня были вот такие записи: авторлибо ты должен всегда вставлять записи AA - BB BB - AA Но я посчитал, что это избыточность, т.к. если 1-ая пословица связана со второй, то и 2-ая ОБЯЗАТЕЛЬНО связана с первой. Не бывает ассиметричности, всегда будет симметричный граф, причем будет повторяющие ключи,, поэтому мне пришлось еще один левый primary ключ создавать, например: id 1 A - B 2 B - A 3 A - C 4 C - A Скорее всего, если пословицы - синонимы, то это отношение транзистивно. То есть, если АА синоним ВВ, и ВВ - синоним СС, то и АА - синоним СС. Если так, то все пословицы в группе синонимов равнозначны между собой, и граф как таковой не нужен. Можно ввести сущность "группа пословиц-синонимов". В ней не будет ни "зеркальных" записей, ни избыточности, и запросы по получению синонимов будут просты. Пословицы ---------- АА ВВ СС DD Группы синонимов ------------------ 1 о природе 2 о труде 3 о социальной справедливости Вхождение пословиц в группы синонимов ----------------------------------------- 1 АА 1 ВВ 1 СС ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2011, 18:20 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
Немного позанудствую > 1) БД должна хранить данные так, как от нее требуется; Кем требуется, зачем требуется? Ваша мысль непонятна > 2) В БД нет графов - есть записи, ключи, таблицы, индексы и многое другое; +1 > 3) Избыточности не бывает - бывает больше записей, чем реально нужно, что бы хранить данные; Избыточность таки бывает (см денормализация) причем даже не связаная с количеством записей. > 4) БД должна быть спроектирована так, Чтобы запросы возвращали правильный результат за приемлимое время. > чтобы запросы из нее были короче Длина запросов рояля не играет, но в кривых плохочитаемых запросов ошибится легче, > а массивы данных обратаваемые такиими запросами - меньше; в общем случае это не верно, хотя часто это так > 5) БД должна быть умной. Т.е. имет ограничения и не давать. То есть если человек ограничен, то он тупой, а если база то она умная. Про не дающих комментировать не буду, я джентельмен > 6) Связь А-Б и Б-А не существует. Бывает 1-много, 1-1, много-к-много. +1, хотя можно было упомянуть про 1-0 и так далее. > Есть направление связи - от меньшего к большему; Если связей не существует то как могут существовать направление связи. > 7) Нормальных форм нет - есть спицифика приложений и особенности работы СУБД. Нормальные формы есть. Приложение может на них забивать, полностью осознавая неприятности которые за этим последуют. Ставить +1 MasterZiv не буду, ибо много придется ставить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2011, 19:22 |
|
||
|
Помогите спроектировать базу данных пословиц
|
|||
|---|---|---|---|
|
#18+
MasterZiv(потому что отношение симметричное) Ну вот это для учебной задачи конечно, а по сути очень большая натяжка. Ближе к реальности следующая модель: есть "пословицы", есть "смыслы" (они же "когда употребляется") и есть многие-ко многим между ними. Например, в некоторых ситуациях "одного поля ягоды" и "яблоко от яблони недалеко падает" - синонимы, а в других - вовсе нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2011, 20:41 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=37531356&tid=1541941]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
161ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
| others: | 214ms |
| total: | 492ms |

| 0 / 0 |
