|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
Изерлонерэто связано с тем что у меня два акса одновременно стоит? оставьте один - 2003-й. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2012, 16:11 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
Изерлонер, так, а вылетает в каком-то одном, конкретном файле ? если создать в А2003 новую БД, и попробывать в ней ТриВью поставить ? как - получится ? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2012, 16:13 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
А2003, остальные приложения офиса - 2010. Работает нормально. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2012, 17:10 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
qwerty112Изерлонер, так, а вылетает в каком-то одном, конкретном файле ? если создать в А2003 новую БД, и попробывать в ней ТриВью поставить ? как - получится ? Создал новую базу, на этот раз в mdb. Сразу попытался поставить на форму Control Tree View. Акс тут же вылетел. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2012, 17:44 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
а вот CTreeView Control нормально встал. Только не уверен что это тоже самое... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2012, 17:47 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
Обратил внимание что Tree View Control вылетает везде при попытке его поставить. В экселе тоже. То есть проблема не в аксе по ходу. А возможно его как-то переустановить? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 08:44 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
С Новым годом! Итак, появилось время что бы более плотно заняться базами данных. На основе примеров Программиста–любителя доработал мою базу и раскидал имеющиеся данные по таблицам... Это конечно не окончательный вариант, но, по крайней мере с этим можно уже работать. Программист–любитель, мне кажется в Вашей схеме данных (с шариковой ручкой) есть некоторая избыточность. Поле sAddress в таблице NodeElement весьма удобно для получения структуры изделия, но оно же приводит к появлению множества дублирующихся записей. Если у нас есть некоторая сборочная единица включающая в себя какое то подмножество деталей, и эта единица включается во множество других сборок – это приведет к появлению в таблице кучи записей о деталях (столько, сколько раз появляется эта сборочная единица в других сборках плюс те же детали входящие в состав других сборочных единиц), отличающихся только по полю sAddress (ну и по сочетанию ID, ID_PARENT). При наличии нескольких сот, а то и тысяч однотипных изделий, таблица сильно разрастется, пожалуй до сотен тысяч записей. П–Л, хочу просто уточнить, так и было задумано? Думаете этим можно пренебречь? Мне кажется от многократного дублирования можно уйти если для адресов создать отдельную таблицу, где и будет хранится структура всех изделий, но это пока только «мысли вслух», возможно в моем случае это не актуально. Мой перечень изделий едва ли превышает две сотни, а там где сборки повторяются ... таких изделий не много больше десятка. ... По крайней мере пока. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2013, 18:26 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
Изерлонертаблица сильно разрастется, пожалуй до сотен тысяч записей. если сотни тысяч записей необходимы для описания ситуации то почему нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2013, 19:23 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
полином, не ну в принципе да, просто это избыточно получается. И мне кажется это количество записей можно многократно сократить. примерно так: описывается структура изделия самого нижнего уровня. Затем описывается структура следующего уровня сборочных единиц, без детализации по нижнему уровню (это уже описано на первом этапе), затем следующий уровень и т.д. А в схеме приведенной П–Л получается для каждого изделия и для каждого уровня полная детализация, из–за чего повторы. Ну если я правильно понял. По крайней мере у меня так получается. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2013, 20:20 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
Изерлонер, моя мысль – отделить адреса узлов (структуру изделий) в отдельную таблицу. В таблице NodeElement оставить только ID, ID_PARENT. Тогда и получается каждый уровень без избыточной детализации. Это сократит количество записей, но возможно я нарвусь на какие–то проблемы которых сейчас не вижу. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2013, 20:27 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
Вот смотрите что я имею ввиду. Вот эта схема. Возьмем например сборочную единицу - пишущий стержень, пусть ID у него будет 0130 В него входят детали Шарик - 2032, сам стержень - 2009, и элемент куда шарик вставляется 3120. Для шарика получаем iElementID = 2032 iElementID_Parent = 0130 nNodeElementCount = 1 sNodeElementAddress =хххх#0130#2032 где хххх - вышестоящие уровни сборок, которых может быть сколько угодно. Один и тот же пишущий стержень может входить в ручки разных моделей, которые в свою очередь могут входить например в разные комплекты и т.д. То есть получаем кучу адресов а с ними и повтор каждый раз всех указанных значений. Как-то так. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2013, 20:57 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
Тыц. Только надо будет как-то отслеживать изменения в таблице NodeElement и вносить изменения в таблицу Structure ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2013, 21:12 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
Ну а это схема моей базы данных на текущий момент (только в части касающейся нормативов расхода). Там еще куча довесков по приходу/расходу (не моя часть, просто импортирую из бухгалтерской базы данных и обрабатываю под свои нужды) и дополнительных проверочных таблиц. Как видите далеко от схемы предложенной П-Л я не ушел, фактически полностью ее передрал. За что ему очень благодарен. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2013, 21:29 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
Изерлонерне ну в принципе да, просто это избыточно получается. И мне кажется это количество записей можно многократно сократить. примерно так: описывается структура изделия самого нижнего уровня. Затем описывается структура следующего уровня сборочных единиц, без детализации по нижнему уровню (это уже описано на первом этапе), затем следующий уровень и т.д. А в схеме приведенной П–Л получается для каждого изделия и для каждого уровня полная детализация, из–за чего повторы. Ну если я правильно понял. По крайней мере у меня так получается. Главное, что я сделал в структуре БД по ТЗ Алекса было единая таблица для всех изделий, сборок, деталей и отдельная таблица о вхождении деталей более нижнего уровня в более крупные единицы. Как ни крути, две таблицы на это надобны. Если бы одна и та же деталь НИКОГДА не включалась бы в РАЗНЫЕ более крупные единицы ОДНОВРЕМЕННО (а только в одну и только одну единицу), то достаточно одной таблицы. А так ID - ParentID надо выносить в отдельную. Далее, поскольку у вас нормальный t-sql дальше все считается запросами. В том числе начав с любого корня - у которого ParentID нулл - вся его полная структура с адресами, расчетом полного количества всех деталюшек, получается мухой рекурсивными запросами. Примеры в топиках я приводил - они абсолютно тривиальны, то же самое есть в bol. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2013, 22:41 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
очень рад продолжению темы, видимо это нужно не только мне, однако структура ручки, как впрочем и тема и структура (изначальная) была предложена мной лишь как наглядный пример имеющийся перед каждым из нас, ну чтоб не впадать в более подробное обсуждение чего-то неведомого или непонятного, на сегодняшний день продолжаю обдумывать изменения структуры, правда большие проблемы с рекурсивностью данных, в смысле выборки данных из нее известными мне способами. В качестве более глубокого обсуждения может быть посмотреть еще раз изначальную структуру (схему) где есть состав Изделий и Сборок отдельно, если это имеет смысл.. постараюсь следить за темой и принимать участие в ней.. С наступившим НОВЫМ ГОДОМ удачи всех благ и главное ЗДОРОВЬЯ!!!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2013, 11:34 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
alex999konочень рад продолжению темы, видимо это нужно не только мне, однако структура ручки, как впрочем и тема и структура (изначальная) была предложена мной лишь как наглядный пример имеющийся перед каждым из нас, ну чтоб не впадать в более подробное обсуждение чего-то неведомого или непонятного, на сегодняшний день продолжаю обдумывать изменения структуры, правда большие проблемы с рекурсивностью данных, в смысле выборки данных из нее известными мне способами. В качестве более глубокого обсуждения может быть посмотреть еще раз изначальную структуру (схему) где есть состав Изделий и Сборок отдельно, если это имеет смысл.. постараюсь следить за темой и принимать участие в ней.. С наступившим НОВЫМ ГОДОМ удачи всех благ и главное ЗДОРОВЬЯ!!!!! Состав изделий и сборок отдельно - в смысле в разных таблицах - грубая ошибка проектирования, вызванная желанием строить физическую модель БД по эскизам входных-выходных форм, отчетов. В t-sql проблем с получением рекурсивных наборов данных нет. В bol'е навалом исчерпывающих примеров. На их основе легко можно рассчитать общее кол-во элементарных деталюшек во всем изделии, одинаковых подсборок и т.п. Тако же количество ресурсов-материалов, время изготовления. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2013, 11:40 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
Программист-Любитель, приветствую!!!! С наступившим Насчет раздельных составов я просто упомянул как о начальной варианте решения, мы это уже обсуждали, да, структура в одной таблице это удобно, да и с рекурсивностью вопрос снимается, просто Излонер задает вопросы как бы в тему, я предлагал просмотреть начальный уровень обсуждения, вдруг да что-нить еще созреет, в смысле решений, ведь чем больше вариантов решения тем более правильный ответ... на связи ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2013, 12:01 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
кстати, прикупил себе 4G роутер Hyawei bm632w пока все работает на ура, во всяком случае лучше чем модем мегафон, да и действительно безлимитный, качай сколько хочешь, правда после скачки 500Гб поставили мне ограничение в 2МБит, а так было стабильно 10 и рывками аж до 15-17 МБит. так к слову пришлось.... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2013, 12:09 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
ну еще скрин про связь 4Г ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2013, 12:13 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
К тому что данные о изделиях, деталях и сборках надо хранить в единой таблице я был подготовлен специалистом по базам данных, который устраивался к нам на работу и которого пнули через полтора месяца. Я упоминал о нем уже. К сожалению сколько либо продолжительно с ним общаться не получилось. Взглянув на то что я сделал на тот момент, похвалил так сказать за старание, сказал что видно что пытаюсь сделать более менее грамотно базу. И главное его замечание было именно о хранении данных в одной таблице. На тот момент для каждого изделия плюс для каждой группы материалов у меня велась отдельная таблица. Он сразу сказал – надо избавляться от этого. Сразу я этого не понял, но далее на собственном опыте создав единую таблицу нормативов в эксель убедился в преимуществах такого подхода. Здесь же на форуме пошли ещё дальше. ... Так, и всё таки мне всё больше не нравится наличие поля адресов в таблице NodeElement. Боюсь из–за дублирования возникнет ситуация когда для изменения количества деталей/подсборок в сборке придется изменять их по каждому изделию куда входит сборка. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2013, 12:37 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
Сейчас компа нет под рукой. Так что на словах – выше, где я привел схему с выделением поля адресов в таблицу Structure вместо поля Name надо сделать FK на поле iElementID и всё. Получаем отдельную таблицу для структуры (адресов) и отдельную таблицу для состава изделий, сборок, подсборок на одном уровне. И никакого лишнего дублирования. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2013, 12:52 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
Изерлонер... Так, и всё таки мне всё больше не нравится наличие поля адресов в таблице NodeElement. Боюсь из–за дублирования возникнет ситуация когда для изменения количества деталей/подсборок в сборке придется изменять их по каждому изделию куда входит сборка. У вас t-sql. Хранить адрес не нужно. Он всегда вычислится на лету, как только будет вам нужен. Проследите логигу выстраивания запросов на таблицах. Внизу - первый уровень - сами таблицы. Информации в них минимум, никаких полей, которые можно вычислить НЕТ. Если открыть голую таблицу, то информация будет очень не наглядна, работать с ней нельзя. (именно работа на голых таблицах была положена в основу приложения Алекса, против чего я кричал благим матом на этом форуме). Следующий слой - запросы. Вот тут данные из разных таблицы соединяются друг с другом, происходит вычисление всего того, что надо. И, наконец - формы! На них информация должна быть представлена именно в таком виде, который привычен и удобен пользователю. Она разительно отличается от физической модели БД (таблиц). Вот тут Алекс может получить свои изделия и сборки отдельно - раз так по ГОСТУ надо юзеру. Дальше - длинный код на sql. Код: sql 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. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2013, 13:11 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
Как всегда ОГРОМНОЕ СПАСИБО!!! за пищу для ума... все равно, у меня пока не получается построить хоть мало-мальски работающее вычисления исходя из струтуры и данных по рекурсивности состава изделия, хотя бы в сторону увеличения входимости, проще говоря пока вообще ничего не получается, вразумительного и приемлемого, даже так скажу- понятного.... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2013, 13:39 |
|
Прошу помощи со схемой данных.
|
|||
---|---|---|---|
#18+
alex999konвсе равно, у меня пока не получается построить хоть мало-мальски работающее вычисления исходя из струтуры и данных по рекурсивности состава изделия, хотя бы в сторону увеличения входимости, проще говоря пока вообще ничего не получается, вразумительного и приемлемого, даже так скажу- понятного.... Прочитать в bol про рекурсивные запросы. Начать с простейшего примера. Получить список всех корней (изделий), включить только минимальный минимум полей ID, ParentID, Name. Сделать рекурсивный запрос, соединеный со списком всех корней через связку ID - ParentID. Получить дерево изделия целиком. Начать добавлять поля и расчеты количества, адреса, и т.п. На все про все от нуля должно уйти полчаса. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2013, 14:10 |
|
|
start [/forum/topic.php?fid=45&msg=38092304&tid=1612569]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 377ms |
total: | 518ms |
0 / 0 |