0 Пользователей и 1 Гость просматривают эту тему.
  • 192 Ответов
  • 29540 Просмотров
*

rsa_m

  • Захожу иногда
  • 254
  • 22 / 0
Re: Компонент для УО (УК и тсж)
« Ответ #30 : 25.01.2013, 10:54:01 »
Внимательно посмотри сам и поймешь, что усложняешь компонент. Своди всё к 5 таблицам, город и адрес это не критические значения.

Согласен что немного громоздкая система таблиц на первый взгляд. Но на самом деле сделана сначала нормализация, а затем денормализация. Т.е. С точки зрения работы с базами данных, там все достаточно логично.
И все нужно. Например в платежке указывается адрес собственника - т.е. таблица адресов нужна. Ну и т.д.
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Re: Компонент для УО (УК и тсж)
« Ответ #31 : 25.01.2013, 10:56:07 »
Пока никакой. Этот этап Я еще не делал, поэтому таблицы пока не продумывал.
Основная ошибка, прежде чем разрабатывать что-либо нужно десять раз продумать структуру и взаимодействие различных элементов.

P.S.: Таблица пользователи уже есть в Joomla - это таблица users.
Создай свою таблицу, с расширенным набором полей и привяжи ее к стандартному пользователю, в эту таблицу можешь и адреса записать и номера счетчиков и лицевые счета (у меня это таблица 1).



Но фраза " посчитали счета и записали их в таблицу 4" - предполагает что в разных регионах страны и даже в разных УК "счет может производиться немного по разному".
Нет, везде умножают какое-либо значение на тариф, т.е. если компонент не планирует накрывать целые регионы, а рассчитан на локальное применение, то всё вполне нормально.

А фраза "юзверю вывели платёжку (каждый может отверстать ее по своему)" - предполагает что должна быть возможность верстки. А как указать что в HTML поле таблицы <td>здесь должна быть сумма по горячей воде</td> нужно вставить значение из какой либо таблицы базы данных Joomla ? Вот для этого Я так понимаю и понадобиться плагин.
Зачем плагин, если это всё делается через views.
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Re: Компонент для УО (УК и тсж)
« Ответ #32 : 25.01.2013, 10:57:35 »
Например в платежке указывается адрес собственника - т.е. таблица адресов нужна. Ну и т.д.
Адрес собственника брать из профиля пользователя.
Сведи все значения воды/газа/электроэнергии и прочего в единую таблицу, это будет проще - меньше запросов.
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

rsa_m

  • Захожу иногда
  • 254
  • 22 / 0
Re: Компонент для УО (УК и тсж)
« Ответ #33 : 25.01.2013, 11:02:33 »
1. Пользователи.
Здесь у меня целый ряд связных таблиц. Третья нормальная форма. Т.е. это есть.

2. Тарифы.
Это есть.
3. Последние показания юзверя.
Есть как замечено только по воде.
Действительно можно свести все показания (и по воде и по газу и по электичеству и т.д. и т.п) в одну таблицу.
4. Счета (храним все).
5. Общие показания по дому.
Да эти таблицы нужно добавить. Пока их нет.
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Re: Компонент для УО (УК и тсж)
« Ответ #34 : 25.01.2013, 11:03:14 »
Если составить базу всех городов Эрэфии еще реально, то таблицу улиц каждого города - уже не реально, а забивать ее никто не будет, проще всего импортнуть значения адресов из той же 1С или обязать пользователя самостоятельно заполнить поля адреса, проверить то их проще, чем забить в базу.
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Re: Компонент для УО (УК и тсж)
« Ответ #35 : 25.01.2013, 11:04:18 »
Здесь у меня целый ряд связных таблиц. Третья нормальная форма. Т.е. это есть.
Вот аналогично сведи в одну таблицу, последующая нагрузка будет меньше.
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Re: Компонент для УО (УК и тсж)
« Ответ #36 : 25.01.2013, 11:07:42 »
Зачем у тебя учитывается куча санузлов? Счетчики на воду ставят в одной точке на вход в квартиру и все.
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

rsa_m

  • Захожу иногда
  • 254
  • 22 / 0
Re: Компонент для УО (УК и тсж)
« Ответ #37 : 25.01.2013, 11:07:46 »
Адрес собственника брать из профиля пользователя.

Я думал над этой темой. Не получается без вмешательства в таблицу users. Нужно заводить в ней доп. поля. Но Я иду по принципу не лезть в движок и не лезть в плане модификации в уже существующие таблицы.

А разбивка таблицы адрес на города и улицы очень удобна.
К примеру у Вас поменялось название улицы. Сейчас при моей организации таблиц, достаточно поменять одно единственное значение в таблице "улицы". А какой геморрой будет если у нас 1000 записей где то в недрах таблицы users, да еще не отдельным полем а единым как поле адрес типа "Москва, ул. Мира, дом 1, кв 1001".
*

rsa_m

  • Захожу иногда
  • 254
  • 22 / 0
Re: Компонент для УО (УК и тсж)
« Ответ #38 : 25.01.2013, 11:08:58 »
Зачем у тебя учитывается куча санузлов? Счетчики на воду ставят в одной точке на вход в квартиру и все.

Если бы было все так просто :)
У нас есть квартиры где 6 счетчиков, по два на каждый стояк (отдельно кухня, туалет, ванна).

Ну и так далее.
Например у Вас офис и в нем два счетчика электроэнергии. Можно конечно пойти по пути - нефиг - суммируйте показания и заносите в одну графу. Но конечный потребитель зачастую начинает требовать чтобы именно по каждому счетчику по отдельности велся учет без компромиссов. Ему дескать так удобнее следить за тем где у него расход больше.

Поэтому Я изначально придал некий запас и гибкость компоненту в этом плане.
« Последнее редактирование: 25.01.2013, 11:13:07 от rsa_m »
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Re: Компонент для УО (УК и тсж)
« Ответ #39 : 25.01.2013, 11:11:03 »
Я же написал - связать таблицу #__users с #__tsj_account, в которую свести все значения (адрес, счетчики, даты и т.д. и т.п.).

У нас есть квартиры где 6 счетчиков, по два на каждый стояк (отдельно кухня, туалет, ванна).
ОК, тогда всё немного усложнится, но один ёрш проще работать с одной таблицей, одним запросом вытягивая значения по всей квартире.
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Re: Компонент для УО (УК и тсж)
« Ответ #40 : 25.01.2013, 11:14:16 »
Для примера посмотри реализацию FLEXIcontent, у тебя получится примерно то же самое, только для профилей пользователя (там для контента).
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

rsa_m

  • Захожу иногда
  • 254
  • 22 / 0
Re: Компонент для УО (УК и тсж)
« Ответ #41 : 25.01.2013, 11:18:56 »
Я же написал - связать таблицу #__users с #__tsj_account, в которую свести все значения (адрес, счетчики, даты и т.д. и т.п.).

А связь есть. У меня таблица #__tsj_account связана с #__users полем.
Из одной таблицы конечно проще. Спору нет. Но появляется избыточность. И не факт что нагрузка на сервак в случае одной большой таблицы будет меньше чем в случае нескольких маленьких. Количество запросов будет несомненно больше, но объем данный может быть в итоге меньше.
А еще на каком то этапе вступит в игру - время отклика системы. И тут для маленьких таблиц оно будет меньше.
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Re: Компонент для УО (УК и тсж)
« Ответ #42 : 25.01.2013, 11:19:09 »
На счет улиц и городов, хорошо, ты берешь id улицы и пишешь в таблицу адреса, а кто будет заполнять таблицу #__tsj_street ? Не усложняй, всё сложное имеет свойство ломаться. По сути - какая разница что выбирать из БД id или значение поля?
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Re: Компонент для УО (УК и тсж)
« Ответ #43 : 25.01.2013, 11:21:06 »
Из одной таблицы конечно проще. Спору нет. Но появляется избыточность. И не факт что нагрузка на сервак в случае одной большой таблицы будет меньше чем в случае нескольких маленьких. Количество запросов будет несомненно больше, но объем данный может быть в итоге меньше.
А еще на каком то этапе вступит в игру - время отклика системы. И тут для маленьких таблиц оно будет меньше.
Не вступит, не будет, объем данных достаточно мал, а лишние запросы съедят больше времени, нежели один вытягивающий сразу всю информацию.
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

rsa_m

  • Захожу иногда
  • 254
  • 22 / 0
Re: Компонент для УО (УК и тсж)
« Ответ #44 : 25.01.2013, 11:22:25 »
На счет улиц и городов, хорошо, ты берешь id улицы и пишешь в таблицу адреса, а кто будет заполнять таблицу #__tsj_street ? Не усложняй, всё сложное имеет свойство ломаться. По сути - какая разница что выбирать из БД id или значение поля?

 ;D
Хорошо что это форум по Joomla. На форуме по SQL и базам данных - порвали бы на 1000 маленьких медвежат это высказывание  ;D
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Re: Компонент для УО (УК и тсж)
« Ответ #45 : 25.01.2013, 11:23:31 »
Хорошо что это форум по Joomla. На форуме по SQL и базам данных - порвали бы на 1000 маленьких медвежат это высказывание  ;D
Не порвали бы, в данном случае и id и название улицы - значения, а сделать выборку по введенной улице много проще, чем селектами выбирать улицу, коих может быть 100+
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

rsa_m

  • Захожу иногда
  • 254
  • 22 / 0
Re: Компонент для УО (УК и тсж)
« Ответ #46 : 25.01.2013, 11:24:35 »
Не вступит, не будет, объем данных достаточно мал, а лишние запросы съедят больше времени, нежели один вытягивающий сразу всю информацию.

Интересный факт. Почему тогда для Битрикс многие хостеры вводят отдельный тариф и даже на отдельный сервак такие сайты выносят? Подозреваю что нагрузка там прет ой-ей-ей какая.
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Re: Компонент для УО (УК и тсж)
« Ответ #47 : 25.01.2013, 11:26:32 »
Интересный факт. Почему тогда для Битрикс многие хостеры вводят отдельный тариф и даже на отдельный сервак такие сайты выносят? Подозреваю что нагрузка там прет ой-ей-ей какая.



Это битрикс! J!2.5 может крутиться на 18Мб оперативы, при этом битрикс даже не начнет установку, а если после установки порезать, то один фиг упадет, сам проверял, где-то была холиварная темка, там этот момент расписывал оч. подробно.
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

rsa_m

  • Захожу иногда
  • 254
  • 22 / 0
Re: Компонент для УО (УК и тсж)
« Ответ #48 : 25.01.2013, 11:32:16 »
Не порвали бы, в данном случае и id и название улицы - значения, а сделать выборку по введенной улице много проще, чем селектами выбирать улицу, коих может быть 100+

А не. Там все намного проще. Нет там нескольких запросов, а только один. Все слепляет по Innerjoin SQL сервак. А запрос всего один проходит.
*

rsa_m

  • Захожу иногда
  • 254
  • 22 / 0
Re: Компонент для УО (УК и тсж)
« Ответ #49 : 25.01.2013, 11:34:25 »
Это битрикс! ....
Ну не интересовался Я почему Битрикс такой. Ну извините :)
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Re: Компонент для УО (УК и тсж)
« Ответ #50 : 25.01.2013, 11:35:19 »
Объясни мне смысл плодить доп. таблицу адресов? Основной вопрос - зачем? Если есть база, то экспорт будет из нее, а руками набивать - глупо, проще чтобы каждый юзверь сделал это сам.
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Re: Компонент для УО (УК и тсж)
« Ответ #51 : 25.01.2013, 11:35:59 »
Блин, нужны программеры! Ребят! Реально нужны советы!
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

rsa_m

  • Захожу иногда
  • 254
  • 22 / 0
Объясни мне смысл плодить доп. таблицу адресов? Основной вопрос - зачем? Если есть база, то экспорт будет из нее, а руками набивать - глупо, проще чтобы каждый юзверь сделал это сам.

Во-первых достоверность информации. Юзер может вбить в адрес все что угодно, а админу потом проверять это придется. А так у меня реализована функция Импорта и CSV файла. Пожалуйста, делаете файл, а компонент его сам по таблицам рассует как надо. И бухгалтер делает CSV файл один раз в принципе.
Во-вторых сама возможность отдельного редактирования записей (например номера дома или ФИО собственника) - это удобно. Сменился собственник у квартиры - залезли в Админ-панель - поменяли в одном месте руками.

А по отдельной таблице адресов, тут тоже просто. Тут достаточно удобно получается.
Смотрите (ну в общем обычная нормализация).
У Вас за каждой квартирой по бухгалтерии закреплен один лицевой счет. И в этом случае действительно не нужно разделять таблицы адресов и лицевых счетов.
Но что если у Вас на один адрес (одну квартиру) приходиться два-три или 10-ть лицевых счетов. А такое встречается сплошь и рядом, для коммунальных квартир, когда у одной квартиры несколько собственников и они хотят платить раздельно и т.д. Тогда для одной единой таблицы получаем большую избыточность. Например для 10 разных лицевых счетов в таблице будет храниться 10 одинаковых адресов, размер базы сильно увеличивается - результат увеличения времени отклика.

P.S.: На самом деле есть некая золотая середина когда нормализация начинает приводить уже не к упрощению, а к усложнению и к большой нагрузке на сервер. Поэтому если разобраться у меня там не третья нормальная форма и не 4я или 5я, а вторая с половиной.
На самом деле когда Я делал эти таблицы Я консультировался с людьми работающими именно с базами. И они помогли мне выбрать эту самую золотую середину. К слову сказать если например до 4йНФ все бить, то таблиц там получается вместо 4х (город, улица, адрес, лицевой счет) что-то порядка 9ти :)
« Последнее редактирование: 25.01.2013, 11:58:22 от rsa_m »
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Так что мешает импортировать сразу адреса, не давая их редактировать? Изменяемый параметр - жилец.
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Но что если у Вас на один адрес (одну квартиру) приходиться два-три или 10-ть лицевых счетов. А такое встречается сплошь и рядом, для коммунальных квартир, когда у одной квартиры несколько собственников и они хотят платить раздельно и т.д. Тогда для одной единой таблицы получаем большую избыточность. Например для 10 разных лицевых счетов в таблице будет храниться 10 одинаковых адресов, размер базы сильно увеличивается - результат увеличения времени отклика.
Здец... Да наплевать юзверям на кол-во собственников! Они хотят получить только инфу о себе, как результат - выборка по пользователю, а не по адресу, адрес вообще нужен только бухам.
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

rsa_m

  • Захожу иногда
  • 254
  • 22 / 0
Здец... Да наплевать юзверям на кол-во собственников! Они хотят получить только инфу о себе, как результат - выборка по пользователю, а не по адресу, адрес вообще нужен только бухам.

Согласен. Так все и сделано, а то что не сделано планируется так сделать.
Пользователь логиниться. После этого мы знаем кто это, т.е. у нас после этого есть его id из базы users.
Далее выборки идут по этому id с точки зрения тарифов, его счетов и т.п.

А адрес нам нужен только когда он платежку хочет распечатать. Он переходит на страницу нужную и только в этот момент из отдельной таблицы адресов происходит выборка самого адреса и вставляется в платежку. В других случаях (когда он показания по счетчикам вводит, просматривает их и т.п.) адрес не участвует вообще никак. И ни какие Select соответственно на отдельную таблицу адресов не идут.

Ну а отдельно эта таблица сделана для того чтобы снова же не править в случае изменения номера дома или номера офиса (квартиры) в 10ти записях таблицы лицевых счетов, а исправить только в 1м единственном месте, одну единственную запись. Там по таблицам везде получается отношение 1 ко многим.
*

rsa_m

  • Захожу иногда
  • 254
  • 22 / 0
Хотя вот с номером дома - это как раз то место где сделана денормализация. А по правилам 3НФ еще должна быть отдельная таблица "Номера Домов", "Номера Квартир". Я себе почти перелом мозга получил когда начал разбираться в нюансах оптимизации баз данных  :o. Там действительно полный ездец.
*

rsa_m

  • Захожу иногда
  • 254
  • 22 / 0
Пока в таблицах 10-100 записей все обычно идет гладко.
Когда из становится 5000-10000 начинают проявляться всякие нехорошести.
Тут конечно еще все зависит и от программиста, т.е. от того как написать запросы. Можно написать так что и при выборке из таблицы в 1000 записей SQL сервак будет загружен сильно.

Я тут нервно посматриваю иногда на одну соседнюю ветку. Иногда проскакивают сообщения по проблемам при большом количестве >50000 записей в таблицах. Думаю этап оптимизации компонента при работе с большими таблицами - еще предстоит где то в будущем  :o.
*

NightGuard

  • Живу я здесь
  • 2927
  • 378 / 7
  • вжжж-вжжж
Возьми и распотроши #__content
Идеология сверхпотребления более опасна для человечества, чем идеология гитлеровского тоталитаризма
*

era

  • Администратор
  • 1587
  • 391 / 5
  • В туалете лучше быть пользователем, чем админом.
по адресам - есть справочник всех адресов Российских - называется КЛАДР.
Он правда большой-большой, но там всё есть ))
Чтобы оставить сообщение,
Вам необходимо Войти или Зарегистрироваться
 

Для чего нужны Plugin Events понятным языком

Автор abrodski

Ответов: 6
Просмотров: 904
Последний ответ 23.05.2023, 17:01:52
от abrodski
Компонент экспорта новстной ленты сайта в Яндекс и Рамблер новости

Автор Dron79

Ответов: 248
Просмотров: 64917
Последний ответ 06.01.2020, 07:36:42
от Altermass
SM FAQ - компонент Вопрос-Ответ для Joomla 2.5+

Автор SmokerMan

Ответов: 680
Просмотров: 143077
Последний ответ 11.10.2019, 23:00:13
от wishlight
Управляющий компонент мультилендига + плюс фронтальная часть

Автор zikkuratvk

Ответов: 0
Просмотров: 832
Последний ответ 06.09.2019, 18:55:37
от zikkuratvk
Компонент чтения логов

Автор AlekVolsk

Ответов: 27
Просмотров: 2888
Последний ответ 16.02.2019, 07:06:24
от stepan39