|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
Dimkas В целом к трёхбуквенным сокращениям привыкаешь очень сильно, они быстро начинают восприниматься как просто термин - все вот эти PRC, PRS, SPR, MNT и т.д. - они ж как родные уже :)) Если человека заставлять ходить раком, он рано или поздно привыкнет, и такой способ для него будет "как родной". Люди сами создают себе проблемы, привыкают к этому и навязывают своё чувство приобретённого комфорта другим. Имел "удовольствие" работать с SAP R/3, с ограничением 4-5 символов в названии. Лютый треш, особо доставляли таблички с названием типа ANAL. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2020, 11:46 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
Dimkas Валерий Юринский Раньше давали короткие имена для экономии памяти. Теперь это неактуально. 1. Пример хотелось привести наиболее короткий, для наглядности, 2. Конкретно эта таблица по-русски называется "Медицинская организация" и везде по документации сокращается до "MO", 3. Система стартовала на Oracle 8i :) В целом к трёхбуквенным сокращениям привыкаешь очень сильно, они быстро начинают восприниматься как просто термин - все вот эти PRC, PRS, SPR, MNT и т.д. - они ж как родные уже :)) На 8i (1999 г.) ресурсов уже было намного больше, чем на Oracle v4, v5, где экономия была неизбежна :-) И вас с "трехбуквенностью", прямо, как у дворника из "12 стульев" :-) "12 стульев" by Ильф и ПетровВ пятницу 15 апреля 1927 года Ипполит Матвеевич, как обычно, проснулся в половине восьмого и сразу же просунул нос в старомодное пенсне с золотой дужкой. Очков он не носил. Однажды, решив, что носить пенсне негигиенично, Ипполит Матвеевич направился к оптику и купил очки без оправы, с позолоченными оглоблями. Очки с первого раза ему понравились, но жена (это было незадолго до ее смерти) нашла, что в очках он вылитый Милюков, и он отдал очки дворнику. Дворник, хотя и не был близорук, к очкам привык и носил их с удовольствием. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2020, 11:53 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
hVostt Имел "удовольствие" работать с SAP R/3, с ограничением 4-5 символов в названии. Лютый треш, особо доставляли таблички с названием типа ANAL. Бооооль Код: plsql 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. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2020, 12:14 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
istrebitel hVostt Имел "удовольствие" работать с SAP R/3, с ограничением 4-5 символов в названии. Лютый треш, особо доставляли таблички с названием типа ANAL. Бооооль Код: plsql 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. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307.
Всё точно, как у нас! Только не смесь французского с нижегородским, а смесь английского с нижнесаксонским :-) Комментарии к таблице - это уже русская доработка, если судить по обилию грамматических ошибок, опечаток, неточностей и недоделок. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Вот это сильная вещь: Код: sql 1. 2.
Точно кто-нибудь перепутает! Это Код: plaintext
Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2020, 15:55 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
Dimkas Валерий Юринский Раньше давали короткие имена для экономии памяти. Теперь это неактуально. 1. Пример хотелось привести наиболее короткий, для наглядности, 2. Конкретно эта таблица по-русски называется "Медицинская организация" и везде по документации сокращается до "MO", 3. Система стартовала на Oracle 8i :) В целом к трёхбуквенным сокращениям привыкаешь очень сильно, они быстро начинают восприниматься как просто термин - все вот эти PRC, PRS, SPR, MNT и т.д. - они ж как родные уже :)) Кто ясно мыслит, тот ясно излагает. (А. Шопенгауэр) Пересмотрел достаточно много баз данных различных МИСов - если вижу такие названия, то всё, туши свет! не база, а помойка, у разработчиков каша в голове, зато апломба до небес! Если у вас двадцать таблиц в БД, то да, ещё можно их хоть как-то закодировать в трёхбуквенные названия, а если в БД триста-четыреста таблиц (а нормальная МИС столько и содержит), то придумать столько коротких названий нереально. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2020, 19:56 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
zeon11 то придумать столько коротких названий нереально. Реально, допустим, всё. Я, например, участвовал в разработке одной нехилой системы (порядка сотни мегабайт собственных исходников на Си), в которой по техническим причинам имена функций были ограничены 8 символами. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2020, 18:38 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
zeon11 Если у вас двадцать таблиц в БД, то да, ещё можно их хоть как-то закодировать в трёхбуквенные названия, а если в БД триста-четыреста таблиц (а нормальная МИС столько и содержит), то придумать столько коротких названий нереально. В той базе, про которую шла речь, на сегодня более 400 таблиц и примерно половина активно используется. Краткие названия (3-4 символа) даны только основным таблицам. Эти же названия являются групповыми префиксами. Производные таблицы (связи, оглавления, журналы и т.д.) имеют более длинные составные имена. Логику составления длинных имен я кратко описывал выше 22195168 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.09.2020, 07:31 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
Dimkas Вот я и говорю, туши свет! 1. Раз есть таблица МО (Медицинские организации), то в этой БД есть и таблица "Страховые организации", таблица "Контрагенты" и прочее. Получается, что на каждый тип организации создается своя таблица. 2. Поля BGDATE, CLDATE (даты введения и прекращения действия). Это хорошая идея, только что вы будете делать, когда выяснится, что медицинская организация временно прекращала несколько раз свою деятельность? Что, будете создавать новую запись для фактически той-же организации? Или придётся перекраивать структуру БД? 3. Поля BGREASON, CLREASON (основание введения в действие, основание прекращения действия) - Поля текстовые, иначе в названиях полей был-бы префикс "ID". Т.е. в эти поля кто ни попадя "льет" всякую шнягу, хотя оснований для начала-прекращения не так много, и вполне их можно оформить в отдельную таблицу, её хотя-бы можно было расширять. 4. Поле CRDATE - дата создания. Это вообще о чём? Дата создания записи? Или дата начала функционирования Медицинской организации? Если первое, то где время, а если второе, то зачем поле BGDATE? 5. Поля MDDATE (дата последнего изменения), MDREASON (основание последнего изменения) - они зачем? Всё-же логируется в таблицу MO_LOG. 6. "при загрузке данных используется промежуточная таблица MO_BUF". Я правильно понимаю, что простым запросом данные не получить, и чтобы пользователю представить актуальные данные необходимо все данные предварительно загрузить в барабан стиральной машинки? 7. В БД есть таблица "Supplier -> SPR", иначе, поставщик. Что будете делать, когда выяснится, что больница решит оказывать услуги сторонним организациям, например, проводить медицинские осмотры для всех автоколонн города? Создавать ещё кучу таблиц, только с логикой "Покупатель-потребитель"? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.09.2020, 16:09 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
zeon11 6. "при загрузке данных используется промежуточная таблица MO_BUF". Я правильно понимаю, что простым запросом данные не получить, и чтобы пользователю представить актуальные данные необходимо все данные предварительно загрузить в барабан стиральной машинки? Хорошая аналогия ... |
|||
:
Нравится:
Не нравится:
|
|||
24.09.2020, 17:01 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
zeon11 5. Поля MDDATE (дата последнего изменения), MDREASON (основание последнего изменения) - они зачем? Всё-же логируется в таблицу MO_LOG. Не занимайтесь пожалуйста проектированием БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.09.2020, 19:14 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
graycode zeon11 5. Поля MDDATE (дата последнего изменения), MDREASON (основание последнего изменения) - они зачем? Всё-же логируется в таблицу MO_LOG. Не занимайтесь пожалуйста проектированием БД. graycode, это не мой велосипед, будьте внимательны в мелочах ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 06:31 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
zeon11, они зачем? Всё-же логируется в таблицу ..._LOG. Если это не ваш велосипед то извините, а ежели ваш, то таких "проектировщиков" лучше держать от проектирования подальше. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 10:41 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
graycode zeon11, они зачем? Всё-же логируется в таблицу ... _LOG . Если это не ваш велосипед то извините, а ежели ваш, то таких "проектировщиков" лучше держать от проектирования подальше. А, теперь понял. Вы огнепламенный борец против "читателей из LOGa". Теперь по порядку. Если пройдёте по ссылке https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&msg=22195168, то увидите, что там есть поле MDDATE - дата последнего изменения , не знаю зачем, но многие разработчики на изменяемые данные делают такое поле. Т.е. изменили данные - сделали пометку. Снова изменили - сделали новую пометку. и т.д. Надо отдать должное, эти разработчики по всей видимости сделали таблицу изменений, назвали её MO_LOG. Так вот, моя мысль заключалась в следующем: если уж разработчикам понадобилась информация о дате последнего изменения, то по правилам нормализации негоже хранить одну и туже информацию в двух местах - поле MDDATE изменяемой таблицы и в отдельной таблице MO_LOG. От чего-то надо отказываться. По мне, в этих условиях (ещё раз - этот велосипед не мой) , так лучше отказаться от поля MDDATE, и прочитать при необходимости всю информацию из таблицы MO_LOG, т.к. она наверняка более информативна. Ну а как эта таблица называется, дело десятое, хоть _LOG, хоть _IZMENENIJA, не я эти таблицы придумываю, но знаю одно, это такие-же таблицы и при необходимости их можно читать. И кстати, как правило эти таблицы не доступны шаловливым ручкам конечных пользователей, а следовательно именно в этих таблицах достоверная информация. P.S. По поводу "проектировщиков". При проектировании своих баз данных стремлюсь к тому, чтобы пользователю были недоступны возможности удалить запись или её изменить. Иными словами, пользователь думает, что он удалил запись или её изменил, на самом деле я "подсовываю" ему новую запись. Таким образом у меня вообще нет таблиц LOG и соответственно я таблицы LOG, как и вы, никогда не читаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 15:06 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
zeon11 Так вот, моя мысль заключалась в следующем: если уж разработчикам понадобилась информация о дате последнего изменения, то по правилам нормализации негоже хранить одну и туже информацию в двух местах - поле MDDATE изменяемой таблицы и в отдельной таблице MO_LOG. В таблице в OLTP системах хранится текущее актуальное состояние объекта и дата последнего изменения это именно текущее актуальное состояние объекта, в таблице лога хранится движение объекта во времени, доставать его тяжело и больно, если для работы системы нужны даты прохождения определенных состояний, то размещать их нужно именно в основной таблице, лог используется для разбора полетов или редко запускаемых отчетов, но никак не для оперативной работы, если вы любите стрелять себе в ногу, дело ваше, жаль что разгребать это после вас придется другим людям. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 17:42 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
Поля "дата последнего изменения" и "автор последнего изменения" с точки зрения бизнес-логики никогда и ни зачем не нужны. По крайней мере, очень трудно вспомнить случай, где они реально понадобились бы. Но у них есть одно ценное свойство - по ним удобно искать. Говорит Вася "я позавчера работал с этим договором" - и Пете этого, как правило, достаточно. Поэтому по цена/качество их нередко стоит поддерживать, не связываясь ради этого с громоздкими дополнительными структурами. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 17:49 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
zeon11 1. Раз есть таблица МО (Медицинские организации) ... Если это один из ключевых объектов системы, то почему нет, к чему такая категоричность? zeon11 2. Поля BGDATE, CLDATE (даты введения и прекращения действия). Это хорошая идея, только что вы будете делать, когда выяснится, что медицинская организация временно прекращала несколько раз свою деятельность? Что, будете создавать новую запись для фактически той-же организации? Или придётся перекраивать структуру БД? В основной таблице хранится текущее актуальное состояние объекта, а для сохранения цепочки периодов действия, на сколько я вижу, предлагается таблица _HIS, так что ничего перекраивать не нужно. zeon11 3. Поля BGREASON, CLREASON (основание введения в действие, основание прекращения действия) - Поля текстовые, иначе в названиях полей был-бы префикс "ID". Т.е. в эти поля кто ни попадя "льет" всякую шнягу, хотя оснований для начала-прекращения не так много, и вполне их можно оформить в отдельную таблицу, её хотя-бы можно было расширять. Если в бизнес процессе не предполагается такой сущности и людей которые будут отвечать за ее ведение, зачем ее вводить? zeon11 4. Поле CRDATE - дата создания. Это вообще о чём? Дата создания записи? Или дата начала функционирования Медицинской организации? Если первое, то где время, а если второе, то зачем поле BGDATE? В Oracle тип DATE содержит время. zeon11 6. "при загрузке данных используется промежуточная таблица MO_BUF". Я правильно понимаю, что простым запросом данные не получить, и чтобы пользователю представить актуальные данные необходимо все данные предварительно загрузить в барабан стиральной машинки? Вы понимаете совершенно неправильно, что впрочем и неудивительно. zeon11 7. В БД есть таблица "Supplier -> SPR", иначе, поставщик. Что будете делать, когда выяснится, что больница решит оказывать услуги сторонним организациям, например, проводить медицинские осмотры для всех автоколонн города? Создавать ещё кучу таблиц, только с логикой "Покупатель-потребитель"? Вы себе не представляете, но в информационных системах бывают даже не таблицы, а целые отдельные модули SRM и CRM)) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 18:10 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
graycode в таблице лога хранится движение объекта во времени, доставать его тяжело и больно Я конечно дико извиняюсь, но если эти данные доставать тяжело и больно, нахрена они тогда такие упёрлись? И какую пользу бизнес-логике приносит дата и время последнего изменения без знания о том, что конкретно менялось? Вот у вас таблица с 50 полями. Вы видите, что Вася автор последних изменений в такое-то время. И чо? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 00:11 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
graycode если вы любите стрелять себе в ногу, дело ваше, жаль что разгребать это после вас придется другим людям Если для вас представляет сложность работа с аудитом изменений, значит у вас ружьё тупо не стреляет. И как охотник с таким ружьём вы нафиг никому не нужны. Зато вы себе ногу не отстрелите, хоть что-то хорошоее, да? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 00:12 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
hVostt, Да да да, а потом начинается разгребание вот таких вот каках 22203332 ... Или биллинги начинают запускать массово, а там сплошняком группировки по максимальной дате по табличке логов весьма неслабых размеров, ой что же делать что же делать, можно как то соптимизировать запросы ... а еще бы логи почистить и оставить в оперативном доступе три последних месяца ... )) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 01:35 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
graycode graycode, что за детский сад? Что вы сюда третьи топики притягиваете? Обиделись, что ваше "гениальное" высказывание Когда оперативные данные нужно получать из лога, это отвратно спроектированная система там проигнорировали? А что на него отвечать, это банальная истина, все её знают, что её обсуждать? И наверняка уважаемый автор того топика это знает. Посмотрите его профиль, у него только в Оракле 1080 сообщений, он на форуме уже 15 лет, а сколько до этого пахал, никто кроме него не знает. И уж про то, что и откуда читать, думаю прекрасно разбирается. И ситуации бывают разные, и информационные системы достаются по наследству, и их надо сопровождать, а не рассуждать, правильно или нет спроектирована система. Поэтому вашу пошлость там проигнорировали. А это что такое? graycode ... ой что же делать что же делать, можно как то соптимизировать запросы ... а еще бы логи почистить и оставить в оперативном доступе три последних месяца ... )) Это влажные мечты, как вы спасаете свой отдел? Все такие носятся от компьютера к компьютеру с факелами зажженными, не знают, что делать, причитают, плачут, руки заламывают, а тут появляетесь вы, весь в белом, золотой венок на голове, как же без него, и произносите: Когда оперативные данные нужно получать из лога, это отвратно спроектированная система ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 16:41 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
graycode Да да да, а потом начинается разгребание вот таких вот каках 22203332 ... Ни одна концепция сама по себе не является серебряной пулей. Вы либо можете концепцию применить так, чтобы она приносила пользу, либо нет. А потом начинается, ООП говно, ФП говно, SOLID говно и т.д. от ребят, которые не осилили ни одной парадигмы из разработки. graycode Или биллинги начинают запускать массово, а там сплошняком группировки по максимальной дате по табличке логов весьма неслабых размеров, ой что же делать что же делать, можно как то соптимизировать запросы ... а еще бы логи почистить и оставить в оперативном доступе три последних месяца ... )) Вариантов решения на сегодняшний момент -- масса. Если кто-то не умеет, или не способен мыслить и решать задачи, это его проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 16:51 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
zeon11 graycode, что за детский сад? Действительно, вам бы не мешало перейти из яслей хотя бы в детский сад. zeon11 Посмотрите его профиль, у него только в Оракле 1080 сообщений, он на форуме уже 15 лет, а сколько до этого пахал, никто кроме него не знает. Зачем мне смотреть его профиль, он в своих топиках до сих пор задает детские вопросы и демонстрирует неспособность работать с документацией, если он делает это на протяжении 15 лет, печально. zeon11 Это влажные мечты Ваши влажные мечты меня как то совсем не интересуют. hVostt Ни одна концепция сама по себе не является серебряной пулей. Не могу не согласиться)) hVostt А потом начинается, ООП говно, ФП говно, SOLID говно и т.д. от ребят, которые не осилили ни одной парадигмы из разработки. В соседней теме вы очень негативно отнеслись к паттерну репозиторий, да и к паре букв из SOLID тоже)) hVostt Вариантов решения на сегодняшний момент -- масса. Если кто-то не умеет, или не способен мыслить и решать задачи, это его проблемы. Масса, да, но они не бесплатные и зачем устраивать себе в OLTP системе геморрой на ровном месте? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 19:18 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
graycode hVostt А потом начинается, ООП говно, ФП говно, SOLID говно и т.д. от ребят, которые не осилили ни одной парадигмы из разработки. В соседней теме вы очень негативно отнеслись к паттерну репозиторий, да и к паре букв из SOLID тоже)) К паттерну репозиторий у меня много претензий, но в основном не к самому паттерну, а к тому как его понимают и применяют. К SOLID, в целом тоже самое. Там где вы ратуете за SRP, вы сами же его жёстко нарушаете, но не понимаете этого. Понимание рано или поздно придёт, если вы не решите сменить область деятельности. Дискутировать вы не захотели, чтобы углубить понимание, решили, что у вас есть "мнение" и этого достаточно. Любая команда будет рада человеку, который придёт со своим мнением, ведь мнение священно, оно у каждого своё и аргументировать его не нужно :) graycode hVostt Вариантов решения на сегодняшний момент -- масса. Если кто-то не умеет, или не способен мыслить и решать задачи, это его проблемы. Масса, да, но они не бесплатные и зачем устраивать себе в OLTP системе геморрой на ровном месте? Да нет никакого геморроя. Я так понимаю, это лично ваш горький опыт. Не думайте, что у всех так. Мы никаких проблем не испытывали с огромным объёмом информации, количеством сущностей, связей и бизнес-логикой. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 22:32 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
hVostt К паттерну репозиторий у меня много претензий, но в основном не к самому паттерну, а к тому как его понимают и применяют. К SOLID, в целом тоже самое. О том как правильно с вашей точки зрения применять вышеозначенные принципы мы узнаем? hVostt Там где вы ратуете за SRP, вы сами же его жёстко нарушаете, но не понимаете этого. Мысли я читать не умею, а каким образом я нарушаю SRP вы рассказать не удосужились. hVostt Дискутировать вы не захотели, чтобы углубить понимание, решили, что у вас есть "мнение" и этого достаточно. О чем дискутировать, если идут общие слова характеризующие мнение и не несущие конкретики, собственно обменялись мнениями и разошлись, каждый при своем мнении)) hVostt Да нет никакого геморроя. Я так понимаю, это лично ваш горький опыт. Не думайте, что у всех так. Мы никаких проблем не испытывали с огромным объёмом информации, количеством сущностей, связей и бизнес-логикой. Снова общие слова, увы они не несут конкретики и не являются аргументацией. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 00:09 |
|
подскажите хорошую практику наименования связанных таблиц
|
|||
---|---|---|---|
#18+
graycode hVostt К паттерну репозиторий у меня много претензий, но в основном не к самому паттерну, а к тому как его понимают и применяют. К SOLID, в целом тоже самое. О том как правильно с вашей точки зрения применять вышеозначенные принципы мы узнаем? Конечно, ведь об этом уже трепались в какой-то из тем. graycode hVostt Там где вы ратуете за SRP, вы сами же его жёстко нарушаете, но не понимаете этого. Мысли я читать не умею, а каким образом я нарушаю SRP вы рассказать не удосужились. Так вы решили прекратить дискуссию в той теме. graycode hVosttДискутировать вы не захотели, чтобы углубить понимание, решили, что у вас есть "мнение" и этого достаточно. О чем дискутировать, если идут общие слова характеризующие мнение и не несущие конкретики, собственно обменялись мнениями и разошлись, каждый при своем мнении)) Не, это вы ушли. Я-то остался :) Честно говоря, мне непонятен термин "мнение" в контексте инженерной дисциплины. Представьте себе, как два математика спорят, один считает, что 2+2=4, а другой считает, что 2+2=5. Понимаете дикий абсурд ситуации? В чём смысл подобного "обмена мнениями" в подобных случаях? Я вот говорю, вы не правы в том топике. И мне как-то всё равно, останетесь вы при своём мнении, или нет. Нет цели вас в чём-то убедить. graycode hVostt Да нет никакого геморроя. Я так понимаю, это лично ваш горький опыт. Не думайте, что у всех так. Мы никаких проблем не испытывали с огромным объёмом информации, количеством сущностей, связей и бизнес-логикой. Снова общие слова, увы они не несут конкретики и не являются аргументацией. Погодите, это вы заикнулись: graycode В таблице в OLTP системах хранится текущее актуальное состояние объекта и дата последнего изменения это именно текущее актуальное состояние объекта, в таблице лога хранится движение объекта во времени, доставать его тяжело и больно И я вам прямо говорю, что тяжело и больно -- исключительно для вас. Так как вы пока не умеете работать с такими данными, ещё не хватает опыта, чтобы сделать такую архитектуру и организацию, чтобы не было тяжело и больно. Какие вам здесь аргументы нужны? Вы и дальше собираетесь настаивать, что такая задача "тяжело и больно" решается для всех? Интересно, если вы столкнётесь с концепцией Event Sourcing, мозги взорвутся и разметаются по стенам? Ведь там вообще мастер-данные это поток событий -- изменений данных, никаких тебе таблиц. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 01:26 |
|
|
start [/forum/topic.php?fid=32&msg=40002442&tid=1539838]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
2ms |
others: | 249ms |
total: | 408ms |
0 / 0 |